From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 15:53:49 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 732BA16A4CE for ; Wed, 20 Oct 2004 15:53:49 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2DB043D1D for ; Wed, 20 Oct 2004 15:53:48 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost.ipv6.lcs.mit.edu [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i9KFrlqw014555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Wed, 20 Oct 2004 11:53:47 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i9KFreme014552; Wed, 20 Oct 2004 11:53:40 -0400 (EDT) (envelope-from wollman) Date: Wed, 20 Oct 2004 11:53:40 -0400 (EDT) From: Garrett Wollman Message-Id: <200410201553.i9KFreme014552@khavrinen.lcs.mit.edu> To: "Ronald F. Guilmette" In-Reply-To: <74506.1098231543@monkeys.com> References: <41757F72.A36AD263@freebsd.org> <74506.1098231543@monkeys.com> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 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 15:53:49 -0000 < 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