All,
I am looking for a C++ wrapper over BSD socket library. I plan to use
socket i/o during telecom call processing in a thread so that thread
is not blocked when it is making read/write call. It can move to next
message processing after saving the current call context. It can
resume the processing of this call when it receive the i/o complete
notification.
thanks
Ittium

On Fri, 18 Feb 2011, junk junk wrote:

>All,
>I am looking for a C++ wrapper over BSD socket library. I plan to use
>socket i/o during telecom call processing in a thread so that thread
>is not blocked when it is making read/write call. It can move to next
>message processing after saving the current call context. It can
>resume the processing of this call when it receive the i/o complete
>notification.
>thanks
>Ittium
>

Why do you want a C++ wrapper? You can call the socket library directly, use the
SOCK_NONBLOCK flag when you call socket(2) and use poll(2) or select(2) to wait
on the data. You can also set the O_ASYNC flag via fcntl(2) and let the kernel
inform you about available data (You'll get the SIGIO signal then).

junk junk wrote:
> All,
> I am looking for a C++ wrapper over BSD socket library. I plan to use
> socket i/o during telecom call processing in a thread so that thread
> is not blocked when it is making read/write call. It can move to next
> message processing after saving the current call context. It can
> resume the processing of this call when it receive the i/o complete
> notification.
> thanks
> Ittium

See the boost asio library from boost.org. Docs are at:

http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio.html

Jeff

On Feb 19, 3:12=A0pm, Tobias Blass <tobiasbl...@gmx.net> wrote:
> On Fri, 18 Feb 2011, junk junk wrote:
> >All,
> >I am looking for a C++ wrapper over BSD socket library. I plan to use
> >socket i/o during telecom call processing in a thread so that thread
> >is not blocked when it is making read/write call. It can move to next
> >message processing after saving the current call context. It can
> >resume the processing of this call when it receive the i/o complete
> >notification.
> >thanks
> >Ittium
>
> Why do you want a C++ wrapper? You can call the socket library directly, =
use the
> SOCK_NONBLOCK flag when you call socket(2) and use poll(2) or select(2) t=
o wait
> on the data. You can also set the O_ASYNC flag via fcntl(2) and let the k=
ernel
> inform you about available data (You'll get the SIGIO signal then).

You are right, I can call the BSD APIs directly. I need C++ wrapper
since rest of the code is in C++.
I am not sure how good will be performance with SIGIO, when a thread
is working upon multiple socket
fd. Let us no forget, the thread safety issues with signal. SELECT and
POLL are definitely promising.

On 02/20/11 06:46 PM, junk junk wrote:
> On Feb 19, 3:12 pm, Tobias Blass<tobiasbl...@gmx.net>  wrote:
>> On Fri, 18 Feb 2011, junk junk wrote:
>>> All,
>>> I am looking for a C++ wrapper over BSD socket library. I plan to use
>>> socket i/o during telecom call processing in a thread so that thread
>>> is not blocked when it is making read/write call. It can move to next
>>> message processing after saving the current call context. It can
>>> resume the processing of this call when it receive the i/o complete
>>> notification.
>>> thanks
>>> Ittium
>>
>> Why do you want a C++ wrapper? You can call the socket library directly, use the
>> SOCK_NONBLOCK flag when you call socket(2) and use poll(2) or select(2) to wait
>> on the data. You can also set the O_ASYNC flag via fcntl(2) and let the kernel
>> inform you about available data (You'll get the SIGIO signal then).
>
> You are right, I can call the BSD APIs directly. I need C++ wrapper
> since rest of the code is in C++.

So?  Most of my code is C++, but I still use the socket API.

> I am not sure how good will be performance with SIGIO, when a thread
> is working upon multiple socket
> fd. Let us no forget, the thread safety issues with signal. SELECT and
> POLL are definitely promising.

Whether you use multiple threads and blocking or non-blocking with poll 
really depends on you workload and whether you can use multiple cores to 
process your data.  On a single core, poll is much easier to use.

-- 
Ian Collins

Tobias Blass <tobiasblass@gmx.net> wrote:
<snip>
> Why do you want a C++ wrapper? You can call the socket library directly, use the
> SOCK_NONBLOCK flag when you call socket(2) and use poll(2) or select(2) to wait
> on the data. You can also set the O_ASYNC flag via fcntl(2) and let the kernel
> inform you about available data (You'll get the SIGIO signal then).

SOCK_NONBLOCK is a Linux extension.

O_ASYNC is tricky to handle because of overflow and other signal handling
issues. Nobody should be using O_ASYNC these days.

On Feb 20, 11:28=A0am, William Ahern <will...@wilbur.25thandClement.com>
wrote:
> Tobias Blass <tobiasbl...@gmx.net> wrote:
>
> <snip>
>
> > Why do you want a C++ wrapper? You can call the socket library directly=
, use the
> > SOCK_NONBLOCK flag when you call socket(2) and use poll(2) or select(2)=
 to wait
> > on the data. You can also set the O_ASYNC flag via fcntl(2) and let the=
 kernel
> > inform you about available data (You'll get the SIGIO signal then).
>
> SOCK_NONBLOCK is a Linux extension.
>
> O_ASYNC is tricky to handle because of overflow and other signal handling
> issues. Nobody should be using O_ASYNC these days.

Problem I am trying to solve is simple
1. Multiple threads want to send the data on a shared socket fd but
they can not perform blocking call since they are highly loaded and
has other tasks to do.
2. Thread want to read from its **exclusive** socket, but it should
not be blocked since it is loaded and has other tasks to do.
I am currently evaluating boost asio
thanks
Ittium

On Sat, 19 Feb 2011, William Ahern wrote:

>Tobias Blass <tobiasblass@gmx.net> wrote:
><snip>
>> Why do you want a C++ wrapper? You can call the socket library directly, use the
>> SOCK_NONBLOCK flag when you call socket(2) and use poll(2) or select(2) to wait
>> on the data. You can also set the O_ASYNC flag via fcntl(2) and let the kernel
>> inform you about available data (You'll get the SIGIO signal then).
>
>SOCK_NONBLOCK is a Linux extension.
>
>O_ASYNC is tricky to handle because of overflow and other signal handling
>issues. Nobody should be using O_ASYNC these days.
>
Ok thank you for the clarification. I just had something in mind that you
could use SIGIO (haven't ever used it myself) so I just looked over the
manpage. If SOCK_NONBLOCK is a linux extension how can you tell the socket
not to block on read(2) on other Unix flavors?

On 02/20/11 10:42 PM, Tobias Blass wrote:
> On Sat, 19 Feb 2011, William Ahern wrote:
>
>> Tobias Blass<tobiasblass@gmx.net>  wrote:
>> <snip>
>>> Why do you want a C++ wrapper? You can call the socket library directly, use the
>>> SOCK_NONBLOCK flag when you call socket(2) and use poll(2) or select(2) to wait
>>> on the data. You can also set the O_ASYNC flag via fcntl(2) and let the kernel
>>> inform you about available data (You'll get the SIGIO signal then).
>>
>> SOCK_NONBLOCK is a Linux extension.
>>
>> O_ASYNC is tricky to handle because of overflow and other signal handling
>> issues. Nobody should be using O_ASYNC these days.
>>
> Ok thank you for the clarification. I just had something in mind that you
> could use SIGIO (haven't ever used it myself) so I just looked over the
> manpage. If SOCK_NONBLOCK is a linux extension how can you tell the socket
> not to block on read(2) on other Unix flavors?

By using fcntl to set the O_NONBLOCK flag on the file descriptor.

-- 
Ian Collins

William Ahern <william@wilbur.25thandClement.com> writes:
> Tobias Blass <tobiasblass@gmx.net> wrote:
> <snip>
>> Why do you want a C++ wrapper? You can call the socket library directly, use the
>> SOCK_NONBLOCK flag when you call socket(2) and use poll(2) or select(2) to wait
>> on the data. You can also set the O_ASYNC flag via fcntl(2) and let the kernel
>> inform you about available data (You'll get the SIGIO signal then).
>
> SOCK_NONBLOCK is a Linux extension.
>
> O_ASYNC is tricky to handle because of overflow and other signal handling
> issues. Nobody should be using O_ASYNC these days.

I disagree with that. O_ASYNC, especially when combined with the
'Linux extensions' for that (meaning, it works for all file
descriptors) is a really useful interface and often, even the one
which is easiest to use one[*].

	[*] One of the programs I presently work on is written in
	Perl. Perl doesn't really offer anything sensible wrt I/O
	multiplexing on its own (I refuse to use select for anything
	and Graham Barr's poll module is implemented in a completely
	braindead way [basically, it make poll inherit the inherent
	deficiencies of select by constructing a new, dynamically allocated
	pollfd array for each call]) and making sigwaitinfo available
	in Perl required far less code than providing a sensible
	poll-interface. Also, this meant being able to use a uniform
	event notification mechanism (signals) for all events I'm
	interested in (I/O readiness notification, SIGALRM, manually
	sent signals, 'child process death' events instead of 'using a
	file-descriptor based approach and shoe-horning signal
	processing into that. 'Signal queue overflow' is easily dealt
	with by simply marking all descriptors as 'I/O ready' and let
	the ordinary I/O event handlers sort the actual descriptor
	states out (they need to be able to deal with this, anyway).
        

Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> William Ahern <william@wilbur.25thandClement.com> writes:
<snip>
> > O_ASYNC is tricky to handle because of overflow and other signal handling
> > issues. Nobody should be using O_ASYNC these days.

> I disagree with that. O_ASYNC, especially when combined with the
> 'Linux extensions' for that (meaning, it works for all file
> descriptors) is a really useful interface and often, even the one
> which is easiest to use one[*].

>         [*] One of the programs I presently work on is written in
>         Perl. Perl doesn't really offer anything sensible wrt I/O
>         multiplexing on its own (I refuse to use select for anything
>         and Graham Barr's poll module is implemented in a completely
>         braindead way [basically, it make poll inherit the inherent
>         deficiencies of select by constructing a new, dynamically allocated
>         pollfd array for each call]) and making sigwaitinfo available
>         in Perl required far less code than providing a sensible
>         poll-interface. Also, this meant being able to use a uniform
>         event notification mechanism (signals) for all events I'm
>         interested in (I/O readiness notification, SIGALRM, manually
>         sent signals, 'child process death' events instead of 'using a
>         file-descriptor based approach and shoe-horning signal
>         processing into that. 'Signal queue overflow' is easily dealt
>         with by simply marking all descriptors as 'I/O ready' and let
>         the ordinary I/O event handlers sort the actual descriptor
>         states out (they need to be able to deal with this, anyway).
>         

Fair enough. The way I figured it, O_ASYNC is on the one hand non-portable,
yet where it is supported there is kqueue or epoll/signalfd, neither of
which require overflow handling or careful signal masking. So I figured, why
use O_ASYNC? But I guess the answer is convenience.

Linux looks like it can deliver the descriptor number with SIGPOLL. Does it
dequeue the signal when the descriptor is closed?

William Ahern <william@wilbur.25thandClement.com> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> William Ahern <william@wilbur.25thandClement.com> writes:
> <snip>
>> > O_ASYNC is tricky to handle because of overflow and other signal handling
>> > issues. Nobody should be using O_ASYNC these days.

[...]

>>         [*] One of the programs I presently work on is written in
>>         Perl. Perl doesn't really offer anything sensible wrt I/O
>>         multiplexing on its own (I refuse to use select for anything
>>         and Graham Barr's poll module is implemented in a completely
>>         braindead way [basically, it make poll inherit the inherent
>>         deficiencies of select by constructing a new, dynamically allocated
>>         pollfd array for each call]) and making sigwaitinfo available
>>         in Perl required far less code than providing a sensible
>>         poll-interface. Also, this meant being able to use a uniform
>>         event notification mechanism (signals) for all events I'm
>>         interested in (I/O readiness notification, SIGALRM, manually
>>         sent signals, 'child process death' events instead of 'using a
>>         file-descriptor based approach and shoe-horning signal
>>         processing into that. 'Signal queue overflow' is easily dealt
>>         with by simply marking all descriptors as 'I/O ready' and let
>>         the ordinary I/O event handlers sort the actual descriptor
>>         states out (they need to be able to deal with this, anyway).
>>         
>
> Fair enough. The way I figured it, O_ASYNC is on the one hand non-portable,
> yet where it is supported there is kqueue or epoll/signalfd, neither of
> which require overflow handling or careful signal masking. So I figured, why
> use O_ASYNC? But I guess the answer is convenience.

I'm actually using epoll/signalfd at the same time in C code but I
have used O_ASYNC in the past whenever it seemed more convenient. But
for Perl, implementing an XS interface to sigtimedwait/ sigwaitinfo
and to the siginfo structure needed just 124 lines of C and a
reasonably usable epoll/ signalfd interface had certainly needed much
more than this (I wrote a 'sensible' poll interface for Perl in the
past [got sold to someone, so I'm not allowed to use it anymore :-(]
and that was already about twice this amount of code.

> Linux looks like it can deliver the descriptor number with SIGPOLL. Does it
> dequeue the signal when the descriptor is closed?

AFAIK not. 

On Feb 22, 8:34=A0pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> William Ahern <will...@wilbur.25thandClement.com> writes:
> > Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> >> William Ahern <will...@wilbur.25thandClement.com> writes:
> > <snip>
> >> > O_ASYNC is tricky to handle because of overflow and other signal han=
dling
> >> > issues. Nobody should be using O_ASYNC these days.
>
> [...]
>
>
>
>
>
>
>
>
>
> >> =A0 =A0 =A0 =A0 [*] One of the programs I presently work on is written=
 in
> >> =A0 =A0 =A0 =A0 Perl. Perl doesn't really offer anything sensible wrt =
I/O
> >> =A0 =A0 =A0 =A0 multiplexing on its own (I refuse to use select for an=
ything
> >> =A0 =A0 =A0 =A0 and Graham Barr's poll module is implemented in a comp=
letely
> >> =A0 =A0 =A0 =A0 braindead way [basically, it make poll inherit the inh=
erent
> >> =A0 =A0 =A0 =A0 deficiencies of select by constructing a new, dynamica=
lly allocated
> >> =A0 =A0 =A0 =A0 pollfd array for each call]) and making sigwaitinfo av=
ailable
> >> =A0 =A0 =A0 =A0 in Perl required far less code than providing a sensib=
le
> >> =A0 =A0 =A0 =A0 poll-interface. Also, this meant being able to use a u=
niform
> >> =A0 =A0 =A0 =A0 event notification mechanism (signals) for all events =
I'm
> >> =A0 =A0 =A0 =A0 interested in (I/O readiness notification, SIGALRM, ma=
nually
> >> =A0 =A0 =A0 =A0 sent signals, 'child process death' events instead of =
'using a
> >> =A0 =A0 =A0 =A0 file-descriptor based approach and shoe-horning signal
> >> =A0 =A0 =A0 =A0 processing into that. 'Signal queue overflow' is easil=
y dealt
> >> =A0 =A0 =A0 =A0 with by simply marking all descriptors as 'I/O ready' =
and let
> >> =A0 =A0 =A0 =A0 the ordinary I/O event handlers sort the actual descri=
ptor
> >> =A0 =A0 =A0 =A0 states out (they need to be able to deal with this, an=
yway).
>
> > Fair enough. The way I figured it, O_ASYNC is on the one hand non-porta=
ble,
> > yet where it is supported there is kqueue or epoll/signalfd, neither of
> > which require overflow handling or careful signal masking. So I figured=
, why
> > use O_ASYNC? But I guess the answer is convenience.
>
> I'm actually using epoll/signalfd at the same time in C code but I
> have used O_ASYNC in the past whenever it seemed more convenient. But
> for Perl, implementing an XS interface to sigtimedwait/ sigwaitinfo
> and to the siginfo structure needed just 124 lines of C and a
> reasonably usable epoll/ signalfd interface had certainly needed much
> more than this (I wrote a 'sensible' poll interface for Perl in the
> past [got sold to someone, so I'm not allowed to use it anymore :-(]
> and that was already about twice this amount of code.
>
> > Linux looks like it can deliver the descriptor number with SIGPOLL. Doe=
s it
> > dequeue the signal when the descriptor is closed?
>
> AFAIK not.


thanks group for the responses
I am curious if posix aio is used for sockets on linux. I did some
googling it seems its support is limited and not stable.
ittium