aio_connect ?

[Julian Elischer]

Garrett Wollman wrote:

><<On Tue, 19 Oct 2004 17:19:03 -0700, "Ronald F. Guilmette" <rfg at monkeys.com> said:
>
>  
>
>>That's it for now... just aio_connect() and aio_accept().  If I think of
>>something else, I'll let you know.
>>    
>>
>
>[lots of Big Picture(R) stuff elided]
>
>This is certainly an interesting model of program design.  However,
>some caution is advised.  Here are the most significant issues:
>
>- FreeBSD doesn't really support POSIX real-time signals, and I
>don't know whether the AIO code implements the signal mechanism at
>all.  (I believe it's conditional in the specification on AIO && RTS.)
>
>- There's very little you can safely do in a signal handler other than
>post a "complete" flag (of type volatile sig_atomic_t) somewhere, or
>call a small number of POSIX-specified functions.
>
>- Even worse, the POSIX committee just discovered that the behavior of
>asynchronous signals is (thanks to changes in C99) now almost
>completely undefined.  It is unlikely that this will be fixed any time
>soon.
>
>You are, on the whole, much safer (with respect to POSIX's ability to
>define the semantics of the operations you want) implementing your
>asynchronous operations using threads.  FreeBSD does not support the
>RTS "start a new thread for signal delivery" mechanism, but with KSE
>it should be fairly easy to dispatch a message to the UTS telling it
>to do so.
>

KSE threading does this by default..

If you make  N threads, you will see N +1 threads. one of which will be 
in ksesig  state.

>
>-GAWollman
>
>_______________________________________________
>freebsd-net at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-net
>To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>  
>