From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 9 18:20:17 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 094B3487; Wed, 9 Jan 2013 18:20:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id AFF1D314; Wed, 9 Jan 2013 18:20:16 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-148-105.hsd1.ca.comcast.net [50.143.148.105]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r09IK9hq002711 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 9 Jan 2013 10:20:09 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <50EDB4D3.2060000@freebsd.org> Date: Wed, 09 Jan 2013 10:20:03 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Richard Sharpe Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? References: <1357608470.6752.22.camel@localhost.localdomain> <1357626412.6752.24.camel@localhost.localdomain> <1357661755.6752.32.camel@localhost.localdomain> <1357744870.8329.7.camel@localhost.localdomain> In-Reply-To: <1357744870.8329.7.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , freebsd-hackers@freebsd.org, Adrian Chadd 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 18:20:17 -0000 On 1/9/13 7:21 AM, Richard Sharpe wrote: > 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. The best implementation of an async framework I've seen is the one that Alan Cox and friends wrote in the code they sold to IronPort/Cisco. It'd be nice if we could get that extracted out and donated/included into something generally available.. even had a #ifdef Linux code path.. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >