Which asynchronous multiplexer is "recommended" to use, select() or
poll().  From the Solaris man pages, I read the following;

"The poll(2) function is preferred  over  this  function.  It must  be
used  when  the number of file descriptors wxceeds FD_SETSIZE"

Linux offers in libevent a "call back" functionality for multiplexing
I/O desccriptors.  Are these functions accepted as portable standard c
libraries?

CJ

spambox1@mindspring.com writes:

>Which asynchronous multiplexer is "recommended" to use, select() or
>poll().  From the Solaris man pages, I read the following;

>"The poll(2) function is preferred  over  this  function.  It must  be
>used  when  the number of file descriptors wxceeds FD_SETSIZE"

>Linux offers in libevent a "call back" functionality for multiplexing
>I/O desccriptors.  Are these functions accepted as portable standard c
>libraries?

poll(2) is a standard "POSIX" function.  Solaris also has "/dev/poll"
(from S2.6 or 7) and event ports (starting in Solaris 10).

Noen of libevent, /dev/poll or event ports are standard.


Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

On Mon, 13 Nov 2006 19:12:38 +0000, Casper H. S. Dik wrote:

> spambox1@mindspring.com writes:
> 
>>Which asynchronous multiplexer is "recommended" to use, select() or
>>poll().  From the Solaris man pages, I read the following;
> 
>>"The poll(2) function is preferred  over  this  function.  It must  be
>>used  when  the number of file descriptors wxceeds FD_SETSIZE"
> 
>>Linux offers in libevent a "call back" functionality for multiplexing I/O
>>desccriptors.  Are these functions accepted as portable standard c
>>libraries?
> 
> poll(2) is a standard "POSIX" function.  Solaris also has "/dev/poll"
> (from S2.6 or 7) and event ports (starting in Solaris 10).
> 
> Noen of libevent, /dev/poll or event ports are standard.
> 

libevent is a userland library. It's not even native to Linux, but rather
can be found in a base install of OpenBSD and NetBSD (where the author
was/is a contributor). libevent is meant as an abstraction over /dev/poll,
select, poll, epoll, kqueue, etc.

To the OP: if you're concerned about which polling interface to use, and
you've already used libevent, I'd say stick to libevent and let _it_ make
the decision for you. On Linux libevent will likely chose epoll, and on
Solaris, /dev/poll (and possible event ports in a future version).

spambox1@mindspring.com writes:
> Which asynchronous multiplexer is "recommended" to use, select() or
> poll().  From the Solaris man pages, I read the following;
>
> "The poll(2) function is preferred  over  this  function.  It must  be
> used  when  the number of file descriptors wxceeds FD_SETSIZE"

Doesn't that sound as if "Solaris" recommended poll? But you can
answer the question yourself: Read the poll- and
select-manpages. Choose the interface that you like better.

William Ahern <william@25thandClement.com> writes:
> On Mon, 13 Nov 2006 19:12:38 +0000, Casper H. S. Dik wrote:

[...]

>> Noen of libevent, /dev/poll or event ports are standard.
>> 
>
> libevent is a userland library.

That doesn't make it any less non-standard.

[...]

> To the OP: if you're concerned about which polling interface to use, and
> you've already used libevent, I'd say stick to libevent and let _it_ make
> the decision for you.

Why?

Rainer Weikusat wrote:
> William Ahern <william@25thandClement.com> writes:
>> On Mon, 13 Nov 2006 19:12:38 +0000, Casper H. S. Dik wrote:
> 
> [...]
> 
>>> Noen of libevent, /dev/poll or event ports are standard.
>>>
>> libevent is a userland library.
> 
> That doesn't make it any less non-standard.

Nope, but it does make it possible for it to be a "you need this
software dependency" situation rather than a "too bad, this code
won't run on your system at all, ever" situation.

   - Logan

Logan Shaw <lshaw-usenet@austin.rr.com> writes:
> Rainer Weikusat wrote:
>> William Ahern <william@25thandClement.com> writes:
>>> On Mon, 13 Nov 2006 19:12:38 +0000, Casper H. S. Dik wrote:
>> [...]
>>
>>>> Noen of libevent, /dev/poll or event ports are standard.
>>>>
>>> libevent is a userland library.
>> That doesn't make it any less non-standard.
>
> Nope, but it does make it possible for it to be a "you need this
> software dependency" situation rather than a "too bad, this code
> won't run on your system at all, ever" situation.

It is impossible to need a software dependency, that would be 'to need
software somethings depens upon'. Considering that standardized and
usually available interfaces do exist, the question remains why one
would want to depend on some library providing a non-standardized glue
layer above various standard and non-standard event handling
mechanisms. Especially considering that the library itself is fairly
large, there should be a significant benefit associated with using it.
Which benefit is this?

"Rainer Weikusat" <rainer.weikusat@sncag.com> wrote in message 
news:87d57qnf2h.fsf@farside.sncag.com...
> Considering that standardized and usually available interfaces do exist,
> the question remains why one would want to depend on some library
> providing a non-standardized glue layer above various standard and
> non-standard event handling mechanisms. Especially considering that the
> library itself is fairly large, there should be a significant benefit
> associated with using it. Which benefit is this?

From <http://monkey.org/~provos/libevent/>:

"Libevent allows for portable application development and provides the most 
scalable event notification mechanism available on an operating system."

Portable development is (in practice) possible by using select() or poll(), 
but if scalability is a concern and you need portability between platforms 
that provide better but incompatible notification mechanisms, using libevent 
or similar makes some sense.

Alex 

"Alex Fraser" <me@privacy.net> writes:
> "Rainer Weikusat" <rainer.weikusat@sncag.com> wrote in message 
> news:87d57qnf2h.fsf@farside.sncag.com...
>> Considering that standardized and usually available interfaces do exist,
>> the question remains why one would want to depend on some library
>> providing a non-standardized glue layer above various standard and
>> non-standard event handling mechanisms. Especially considering that the
>> library itself is fairly large, there should be a significant benefit
>> associated with using it. Which benefit is this?
>
> From <http://monkey.org/~provos/libevent/>:
>
> "Libevent allows for portable application development and provides the most 
> scalable event notification mechanism available on an operating
> system."

The first statement is false: An application depending on a particular
library is less portable than an application that doesn't. The second
is a statement of fact (Which may or may be not true. That would need
to be checked for each combination of hardware and software the
libevent-using application is intended to run on). 

> Portable development is (in practice) possible by using select() or poll(), 
> but if scalability is a concern and you need portability between platforms 
> that provide better but incompatible notification mechanisms, using libevent 
> or similar makes some sense.

I happen to have such an application, whose only (present and likely
ever) target system is Linux (used on 2.4, eventually 2.6 some
day). This application use RT-signals for event notification. The
implementation consistes of 277 lines of text (including comments ans
blank lines). The interface between the event module and the other
code is sufficiently generic that using a different event notification
mechanism would be possible. Conditionally adding a different event
notification mechanism would require less code, because there would be
no need to deal with the possiblity of a signal queue overflow.

Leaving the consideration that I may not actually be writing code that
is intended to be used, but just to demonstrate something for a thesis
I am writing aside, what benefits do the 19.633 SLOC libevent consists
of offer?

Rainer Weikusat wrote:
> "Alex Fraser" <me@privacy.net> writes:

>> "Libevent allows for portable application development and provides the most 
>> scalable event notification mechanism available on an operating
>> system."
> 
> The first statement is false: An application depending on a particular
> library is less portable than an application that doesn't.

That's not true in the general case.

It is true in the case that the software without the dependency is
written in a portable manner.  But in some cases, doing that is
a non-trivial problem.  It may be a problem that can be solved once
by the library.  In that case, although it would be *possible* to do
it with or without the library, it would be *easier* to do it with
the library.

Whether it introduces more problems than it solves is a function of
the library's implementation.  Does its license allow it to be
bundled with the software that uses it?  Is it small and efficient
enough (compared to doing it yourself) that using it doesn't cause
performance problems or bloat?  Can it be built as a static library
so that it doesn't complicate the installation?  If all of these are
true, there is little reason not to use the library.

   - Logan

Logan Shaw <lshaw-usenet@austin.rr.com> writes:
> Rainer Weikusat wrote:
>> "Alex Fraser" <me@privacy.net> writes:
>>> "Libevent allows for portable application development and provides
>>> the most scalable event notification mechanism available on an
>>> operating
>>> system."
>> The first statement is false: An application depending on a
>> particular
>> library is less portable than an application that doesn't.
>
> That's not true in the general case.
>
> It is true in the case that the software without the dependency is
> written in a portable manner.

A program that is written for a specific virtual machine does not work
on any system where the software providing the virtual machine
environment is not available. Consequently, the program itself is not
portable at all.

> But in some cases, doing that is a non-trivial problem.
> It may be a problem that can be solved once by the library.  In that
> case, although it would be *possible* to do it with or without the
> library, it would be *easier* to do it with the library.

This isn't necessarily true (using interface A instead of interface B
can be easier or more complicated, depending on the interfaces and the
person trying to use them), but even if it was, it would just be a
general statement without relation to a particular situation.

> Whether it introduces more problems than it solves is a function of
> the library's implementation.  Does its license allow it to be
> bundled with the software that uses it?  Is it small and efficient
> enough (compared to doing it yourself) that using it doesn't cause
> performance problems or bloat?  Can it be built as a static library
> so that it doesn't complicate the installation?  If all of these are
> true, there is little reason not to use the library.

And if it the suns happens to be shining, it usually doesn't rain at
the same time. If you look to the left, you will not notice something
happening on the right easily etc.

After three content-free attempts to avoid answering a simple question,
the safe conclusion appears to be that advantages libevent may have
are at least not generally known.

Rainer Weikusat wrote:
> Logan Shaw <lshaw-usenet@austin.rr.com> writes:
> > Rainer Weikusat wrote:
> >> "Alex Fraser" <me@privacy.net> writes:
> >>> "Libevent allows for portable application development and provides
> >>> the most scalable event notification mechanism available on an
> >>> operating
> >>> system."
> >> The first statement is false: An application depending on a
> >> particular
> >> library is less portable than an application that doesn't.
> >
> > That's not true in the general case.
> >
> > It is true in the case that the software without the dependency is
> > written in a portable manner.
>
> A program that is written for a specific virtual machine does not work
> on any system where the software providing the virtual machine
> environment is not available. Consequently, the program itself is not
> portable at all.
>
> > But in some cases, doing that is a non-trivial problem.
> > It may be a problem that can be solved once by the library.  In that
> > case, although it would be *possible* to do it with or without the
> > library, it would be *easier* to do it with the library.
>
> This isn't necessarily true (using interface A instead of interface B
> can be easier or more complicated, depending on the interfaces and the
> person trying to use them), but even if it was, it would just be a
> general statement without relation to a particular situation.
>
> > Whether it introduces more problems than it solves is a function of
> > the library's implementation.  Does its license allow it to be
> > bundled with the software that uses it?  Is it small and efficient
> > enough (compared to doing it yourself) that using it doesn't cause
> > performance problems or bloat?  Can it be built as a static library
> > so that it doesn't complicate the installation?  If all of these are
> > true, there is little reason not to use the library.
>
> And if it the suns happens to be shining, it usually doesn't rain at
> the same time. If you look to the left, you will not notice something
> happening on the right easily etc.
>
> After three content-free attempts to avoid answering a simple question,
> the safe conclusion appears to be that advantages libevent may have
> are at least not generally known.


Thanks to all that posted, the discussion was informative.
Comparisons of select, poll, and libevent seem to indicate that
select/poll out preform libevent, while the libevent api makes
development and long term maintenance "simplier."  (I have never
use libevent and cannot be sure that is true or not.)

I have been using poll() exclusively for decades.  Its millisecond
granularity fits well for the "events" I am polling.

I wirte for many variants of UNIX/Linux, so portability is a higher
concern.  On some Linux distributions, I have found "issues" using
poll -- way off topic from this thread.

My post was just to keep informed that poll is not being "depreciated"
or that using select is "advised" over poll.

Thanks again, you have answered my question.

On Wed, 15 Nov 2006 11:39:42 +0100, Rainer Weikusat wrote:

> I happen to have such an application, whose only (present and likely
> ever) target system is Linux (used on 2.4, eventually 2.6 some
> day). This application use RT-signals for event notification. The
> implementation consistes of 277 lines of text (including comments ans
> blank lines).

 Wow. Less than 300 lines for a complete edge triggered event API? I'm
impressed. I assume it's somewhat specific to your application, but even
so.

> The interface between the event module and the other
> code is sufficiently generic that using a different event notification
> mechanism would be possible. Conditionally adding a different event
> notification mechanism would require less code, because there would be
> no need to deal with the possiblity of a signal queue overflow.

 Well, more code overall ... but less for that specific backend, I assume
you meant :).

> Leaving the consideration that I may not actually be writing code that
> is intended to be used, but just to demonstrate something for a thesis
> I am writing aside, what benefits do the 19.633 SLOC libevent consists
> of offer?

 Absolutely nothing for you. For others there is a generic event API,
which has multiple backends already, this is the main advantage. There are
also some, IMO, questionable "utility" APIs

-- 
/home/james/.signatures/full

On Thu, 16 Nov 2006 10:18:26 -0800, CJ wrote:
<snip>
> Thanks to all that posted, the discussion was informative. Comparisons
> of select, poll, and libevent seem to indicate that select/poll out
> preform libevent, while the libevent api makes development and long term
> maintenance "simplier."  (I have never use libevent and cannot be sure
> that is true or not.)

How did you derive that conclusion. I didn't see any discussion about the
relative performance of _libevent_ versus select/poll, probably
because a user-land library and a system primitive are somewhat orthogonal.

Actually, technically speaking an application using libevent should
performance at _least_ as well as a straight poll/select loop, and on
most modern Unices--and as the number of descriptors increases--a libevent
application will performance substantially better than a poll/select loop,
because neither of those two interfaces scale well with the size of
descriptor sets, and libevent can transparently make use of move native
scalable polling interfaces (RT signals, epoll, kqueue, /dev/poll, etc).

> I have been using poll() exclusively for decades.  Its millisecond
> granularity fits well for the "events" I am polling.

This statement seems suspect since it can be construed as alluding to a
type of busy loop. Strictly speaking the granularity of a descriptor event
viz-a-vie a clock doesn't make sense. Most or no I/O event
frameworks queue and trigger events based on a wall clock; they're either
edge-triggered or level-triggered, based on the actual I/O operations
themselves.

> I wirte for many variants of UNIX/Linux, so portability is a higher
> concern.  On some Linux distributions, I have found "issues" using poll
> -- way off topic from this thread.
> 
> My post was just to keep informed that poll is not being "depreciated"
> or that using select is "advised" over poll.
> 

An argument could be made that select() is more portable. poll() is a SysV
invention, but many network stacks provide only a BSD Sockets
interface, and thus select().

William Ahern <william@25thandClement.com> writes:
> On Thu, 16 Nov 2006 10:18:26 -0800, CJ wrote:
> <snip>
>> Thanks to all that posted, the discussion was informative. Comparisons
>> of select, poll, and libevent seem to indicate that select/poll out
>> preform libevent, while the libevent api makes development and long term
>> maintenance "simplier."  (I have never use libevent and cannot be sure
>> that is true or not.)
>
> How did you derive that conclusion. I didn't see any discussion about the
> relative performance of _libevent_ versus select/poll, probably
> because a user-land library and a system primitive are somewhat orthogonal.
>
> Actually, technically speaking an application using libevent should
> performance at _least_ as well as a straight poll/select loop,

Your second sentence contradicts your first, because it, too,
expresses and opinion regarding the relative performance of the two
approaches out of the blue. And the statement is again so general that
it is content-free: There is no reason to expect that a particular
implementation of something should have any characterics relative to
any other implementation of something, when viewed at this level of
abstraction. A comparison of the two actual implementations would be
necessary. 

> and on most modern Unices--and as the number of descriptors
> increases--a libevent application will performance substantially
> better than a poll/select loop, because neither of those two
> interfaces scale well with the size of descriptor sets, and libevent
> can transparently make use of move native scalable polling
> interfaces (RT signals, epoll, kqueue, /dev/poll, etc).

But the number of descriptors does not increase for a lot of usual
applications. And in an application where it actually does, using a
different system interface is entirely possible without using a
library wrapping it, so this argument is sort of pointless: If you
have large number of descriptors (and 'large number' would need to be
defined), interfaces that avoid some of the overhead associated with
select or poll may perform better and likely will.

>> I have been using poll() exclusively for decades.  Its millisecond
>> granularity fits well for the "events" I am polling.
>
> This statement seems suspect since it can be construed as alluding to a
> type of busy loop.

'busy loop' usually refers to loops like they are used, for instance,
in spinlocks, ie without relinquishing the CPU at all. 

[...]

>> My post was just to keep informed that poll is not being "depreciated"
>> or that using select is "advised" over poll.
>
> An argument could be made that select() is more portable. poll() is a SysV
> invention, but many network stacks provide only a BSD Sockets
> interface, and thus select().

Both a standardized UNIX(*)-interfaces and there is no sui generis
reason to assume that really old BSD-code is used more often than
really old SysV code.

Rainer Weikusat <rainer.weikusat@sncag.com> writes:

>But the number of descriptors does not increase for a lot of usual
>applications. And in an application where it actually does, using a
>different system interface is entirely possible without using a
>library wrapping it, so this argument is sort of pointless: If you
>have large number of descriptors (and 'large number' would need to be
>defined), interfaces that avoid some of the overhead associated with
>select or poll may perform better and likely will.

Quite.  And poll() often is easier/better to use for the "fixed low
number of filedescriptors".

(The one advantage over select is that code using poll does not have
a compiled-in limit on the maximum fd value)

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

On Fri, 17 Nov 2006 12:27:32 +0100, Rainer Weikusat wrote:

> William Ahern <william@25thandClement.com> writes:
>> On Thu, 16 Nov 2006 10:18:26 -0800, CJ wrote: <snip>
>>> Thanks to all that posted, the discussion was informative. Comparisons
>>> of select, poll, and libevent seem to indicate that select/poll out
>>> preform libevent, while the libevent api makes development and long
>>> term maintenance "simplier."  (I have never use libevent and cannot be
>>> sure that is true or not.)
>>
>> How did you derive that conclusion. I didn't see any discussion about
>> the relative performance of _libevent_ versus select/poll, probably
>> because a user-land library and a system primitive are somewhat
>> orthogonal.
>>
>> Actually, technically speaking an application using libevent should
>> performance at _least_ as well as a straight poll/select loop,
> 
> Your second sentence contradicts your first, because it, too, expresses
> and opinion regarding the relative performance of the two approaches out
> of the blue. And the statement is again so general that it is
> content-free: There is no reason to expect that a particular
> implementation of something should have any characterics relative to any
> other implementation of something, when viewed at this level of
> abstraction. A comparison of the two actual implementations would be
> necessary.

If two pieces of software used poll(); one in its own event loop and the
other using libevent, barring any extraordinary circumstances they both
would exhibit the same ORDER of computational complexity (i.e. for
poll() O(N) on the polling operation).

I'm not saying people shouldn't write their own events loops. If you have
a single UDP socket, it probably doesn't matter whether you use poll(),
select() or just plain blocking reads.

The OP said that he was already familiar with libevent, so I merely
suggested that if he had no reason _not_ to use libevent, why re-invent
a wheel?

<snip>
>>> I have been using poll() exclusively for decades.  Its millisecond
>>> granularity fits well for the "events" I am polling.
>>
>> This statement seems suspect since it can be construed as alluding to a
>> type of busy loop.
> 
> 'busy loop' usually refers to loops like they are used, for instance, in
> spinlocks, ie without relinquishing the CPU at all.
> 
> [...]

If you've ever seen a novice write network applications many will start
w/ a busy loop. When they start an instance of top(1) and notice the CPU
churning away at 100%, they begin to insert small millisecond sleeps.

>>> My post was just to keep informed that poll is not being "depreciated"
>>> or that using select is "advised" over poll.
>>
>> An argument could be made that select() is more portable. poll() is a
>> SysV invention, but many network stacks provide only a BSD Sockets
>> interface, and thus select().
> 
> Both a standardized UNIX(*)-interfaces and there is no sui generis reason
> to assume that really old BSD-code is used more often than really old SysV
> code.

Winsock provides select(), but not poll(). You can write portable
socket applications which run on non-Unix platforms.

William Ahern <william@25thandClement.com> writes:
> On Fri, 17 Nov 2006 12:27:32 +0100, Rainer Weikusat wrote:
>> William Ahern <william@25thandClement.com> writes:

[...]

>>> Actually, technically speaking an application using libevent should
>>> performance at _least_ as well as a straight poll/select loop,
>> 
>> Your second sentence contradicts your first, because it, too, expresses
>> and opinion regarding the relative performance of the two approaches out
>> of the blue. And the statement is again so general that it is
>> content-free: There is no reason to expect that a particular
>> implementation of something should have any characterics relative to any
>> other implementation of something, when viewed at this level of
>> abstraction. A comparison of the two actual implementations would be
>> necessary.
>
> If two pieces of software used poll(); one in its own event loop and the
> other using libevent, barring any extraordinary circumstances they both
> would exhibit the same ORDER of computational complexity (i.e. for
> poll() O(N) on the polling operation).

Your original statement was about performance and not about asymptotic
bounds for performance variation for varying number of
descriptors. And your statement above could still apply or not apply
to any pair of implementations you would actually be comparing.

> I'm not saying people shouldn't write their own events loops. If you have
> a single UDP socket, it probably doesn't matter whether you use poll(),
> select() or just plain blocking reads.

It does matter, depending on what you are trying to accomplish, and
the 'general technical recommendation' would be to use poll in this
case, because

	a) the interface isn't based on performance hacks only
	   applicable to VAXen running an early 4BSD.

	b) for a small number of descriptors, poll needs less space
           to describe the interesting events than select does.

	c) poll does not destroy its arguments, meaning they don't
	   need to be reinitialized on each iteration of an event-loop.           
        
> The OP said that he was already familiar with libevent, so I merely
> suggested that if he had no reason _not_ to use libevent, why re-invent
> a wheel?

Software is not composed of wheels and most human interventions are
not going to be used without essential modifications for a couple of
thousands of years, meaning this is a really bad analogy.


[...]

>> Both a standardized UNIX(*)-interfaces and there is no sui generis reason
>> to assume that really old BSD-code is used more often than really old SysV
>> code.
>
> Winsock provides select(), but not poll().

DOS provides neither. So what?

Rainer Weikusat wrote:
> William Ahern <william@25thandClement.com> writes:
> > On Fri, 17 Nov 2006 12:27:32 +0100, Rainer Weikusat wrote:
> >> William Ahern <william@25thandClement.com> writes:
>
> [...]
>
> >>> Actually, technically speaking an application using libevent should
> >>> performance at _least_ as well as a straight poll/select loop,
> >>
> >> Your second sentence contradicts your first, because it, too, expresses
> >> and opinion regarding the relative performance of the two approaches out
> >> of the blue. And the statement is again so general that it is
> >> content-free: There is no reason to expect that a particular
> >> implementation of something should have any characterics relative to any
> >> other implementation of something, when viewed at this level of
> >> abstraction. A comparison of the two actual implementations would be
> >> necessary.
> >
> > If two pieces of software used poll(); one in its own event loop and the
> > other using libevent, barring any extraordinary circumstances they both
> > would exhibit the same ORDER of computational complexity (i.e. for
> > poll() O(N) on the polling operation).
>
> Your original statement was about performance and not about asymptotic
> bounds for performance variation for varying number of
> descriptors. And your statement above could still apply or not apply
> to any pair of implementations you would actually be comparing.
>
> > I'm not saying people shouldn't write their own events loops. If you have
> > a single UDP socket, it probably doesn't matter whether you use poll(),
> > select() or just plain blocking reads.
>
> It does matter, depending on what you are trying to accomplish, and
> the 'general technical recommendation' would be to use poll in this
> case, because
>
> 	a) the interface isn't based on performance hacks only
> 	   applicable to VAXen running an early 4BSD.
>
> 	b) for a small number of descriptors, poll needs less space
>            to describe the interesting events than select does.
>
> 	c) poll does not destroy its arguments, meaning they don't
> 	   need to be reinitialized on each iteration of an event-loop.
>
> > The OP said that he was already familiar with libevent, so I merely
> > suggested that if he had no reason _not_ to use libevent, why re-invent
> > a wheel?
>
> Software is not composed of wheels and most human interventions are
> not going to be used without essential modifications for a couple of
> thousands of years, meaning this is a really bad analogy.
>
>
> [...]
>
> >> Both a standardized UNIX(*)-interfaces and there is no sui generis reason
> >> to assume that really old BSD-code is used more often than really old SysV
> >> code.
> >
> > Winsock provides select(), but not poll().
>
> DOS provides neither. So what?

I found this evaluation of the various multiplexers and is where I
learned about
libevent and epoll.  I let all read and arrive at their own conclusions
at to which
performs better.  I have never used epoll, or libevent and cannot speak
to either.

http://bcr2.uwaterloo.ca/~brecht/papers/getpaper.php?file=ols-2004.pdf

I find poll() easier to code, less likely to be abused, i.e. forgetting
to sent
nfds to one plus the highest FD in the fd_set, and result event parsing
more
useful for my needs.

Again, thanks