From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 20:52:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBD3E16A4CE for ; Wed, 20 Oct 2004 20:52:03 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98B0943D31 for ; Wed, 20 Oct 2004 20:52:03 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id 77B0554A7; Wed, 20 Oct 2004 13:52:03 -0700 (PDT) To: Garrett Wollman In-reply-to: Your message of Wed, 20 Oct 2004 11:53:40 -0400. <200410201553.i9KFreme014552@khavrinen.lcs.mit.edu> Date: Wed, 20 Oct 2004 13:52:03 -0700 Message-ID: <79155.1098305523@monkeys.com> From: "Ronald F. Guilmette" cc: freebsd-net@freebsd.org Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 20:52:04 -0000 In message <200410201553.i9KFreme014552@khavrinen.lcs.mit.edu>, you wrote: >< 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.