In message <[EMAIL PROTECTED]>, you 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.
It is very gentlemanly of you to say so. Thank you. >However, >some caution is advised. Here are the most significant issues: > >- FreeBSD doesn't really support POSIX real-time signals, I think that is entirely orthogonal to the issue we were discussing, which was just async I/O. There is no clear or obvious dependence of aio_*() on anything which could be called ``real time'', in the traditional sense. I certainly _do not_ expect that if I made use of aio_*() functions (with signaling) that I and/or my userland program would then receive notifications of I/O completions within any given small interval after the I/O completions actually occured. There might be big time lags before _I_ actually receive the completion notifications, e.g. if other higher priority processes get scheduled before mine. That's OK. Even if the aio_*() functions don't give me any sort of ``real time'' capabilities, I still do like the ``interrupt me when you are done'' model of I/O _and_ especially what it might allow me to do in the way of better modularizaion of the programs I have which need to do different things on different sockets concurrently. >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.) Well, I don't actually _have_ copies of the more recent POSIX standards... I actually have nothing fresher than about 1992... so I can't easily check that. (I wish that I did, but those documents tend to be EXPEN$IVE.) In any case, it makes no difference. The bottom line is that aio_*() with signaling capabilities (for completions) would be a Nice Thing To Have, regardless of which standard(s) such capabilities are or are not required in. >- 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. Yes, yes. I know. (I was on the ANSI C language standard comittee for awhile, long long ago, so I am well familiar with sig_atomic_t and also all of the arcane _theoretical_ limitations regarding what can and can't be done, standard-conformantly, in a signal handlers. But of course we both know that in addition to just writing sig_atomic_t thingies, in practice it is possible to do lots lots more without actually breaking anything. And if one uses ``thread safe'' libraries, then you can get away with doing even more in/from a signal handler.) >- Even worse, the POSIX committee just discovered that the behavior of >asynchronous signals is (thanks to changes in C99) now almost >completely undefined. Umm... Could you elaborate on that please? Where could I find more infor- mation about what you just said. I _relly_ want to read about this. _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
