Garrett Wollman wrote:
<<On Tue, 19 Oct 2004 17:19:03 -0700, "Ronald F. Guilmette" <[EMAIL PROTECTED]> 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
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
