Date: Wed, 20 Oct 2004 11:53:40 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: freebsd-net@freebsd.org Subject: Re: aio_connect ? Message-ID: <200410201553.i9KFreme014552@khavrinen.lcs.mit.edu> In-Reply-To: <74506.1098231543@monkeys.com> References: <41757F72.A36AD263@freebsd.org> <74506.1098231543@monkeys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Tue, 19 Oct 2004 17:19:03 -0700, "Ronald F. Guilmette" <rfg@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. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410201553.i9KFreme014552>