From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 9 15:21:14 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA62D92F for ; Wed, 9 Jan 2013 15:21:14 +0000 (UTC) (envelope-from rsharpe@richardsharpe.com) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) by mx1.freebsd.org (Postfix) with ESMTP id 78EDE7E5 for ; Wed, 9 Jan 2013 15:21:13 +0000 (UTC) Received: (qmail 41294 invoked by uid 89); 9 Jan 2013 15:21:12 -0000 Received: from unknown (HELO ?192.168.2.23?) (rsharpe@richardsharpe.com@108.225.16.199) by mail.richardsharpe.com with ESMTPA; 9 Jan 2013 15:21:12 -0000 Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Richard Sharpe To: Adrian Chadd In-Reply-To: References: <1357608470.6752.22.camel@localhost.localdomain> <1357626412.6752.24.camel@localhost.localdomain> <1357661755.6752.32.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Jan 2013 07:21:10 -0800 Message-ID: <1357744870.8329.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 15:21:14 -0000 On Tue, 2013-01-08 at 09:20 -0800, Adrian Chadd wrote: > On 8 January 2013 08:15, Richard Sharpe wrote: > > On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote: > >> .. or you could abstract it out a bit and use freebsd's > >> aio_waitcomplete() or kqueue aio notification. > >> > >> It'll then behave much saner. > > > > Yes, going forward that is what I want to do ... this would work nicely > > with a kqueue back-end for Samba's tevent subsystem, and if someone has > > not already written such a back end, I will have to do so, I guess. > > Embrace FreeBSD's nice asynchronous APIs for doing things! You know you want to! > > (Then, convert parts of samba over to use grand central dispatch... :-) > > Seriously though - I was doing network/disk IO using real time signals > what, 10 + years ago on Linux and it plain sucked. AIO + kqueue + > waitcomplete is just brilliant. kqueue for signal delivery is also > just brilliant. Just saying. The problem with a fully event-driven approach is that it will not work, it seems to me. Eventually, you find something that is not async and then you have to go threaded. (Because handling multiple clients in one process is very useful and you do not want client-A's long-running op preventing client-B's short-running op from being serviced.) Then, you run into problems like Posix's insistence that all threads in a process must use the same credentials (ie, uid and gids must be the same across all threads), although there is a hack on Linux to work around this behind glibc's back.