From owner-freebsd-hackers Mon Jul 5 6:54:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay02.esat.net (relay02.esat.net [192.111.39.21]) by hub.freebsd.org (Postfix) with ESMTP id 5638A14DA7 for ; Mon, 5 Jul 1999 06:54:45 -0700 (PDT) (envelope-from niall@pobox.com) Received: from (pobox.com) [193.120.161.36] by relay02.esat.net with esmtp id 1119Cg-0007DJ-00; Mon, 5 Jul 1999 14:54:38 +0100 Message-ID: <3780B8D5.C32D210C@pobox.com> Date: Mon, 05 Jul 1999 14:53:25 +0100 From: Niall Smart X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Zach Brown Cc: Jonathan Lemon , Mike Smith , hackers@FreeBSD.ORG Subject: Re: poll() scalability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Also, you really want to return more than one event at at time in > > order to amortize the cost of the system call over several events, this > > doesn't seem possible with callbacks (or upcalls). > > yes, that would be a nice behaviour, but I haven't seen it become a real > issue yet. the sigwaitinfo() syscall is just so much lighter than all the > other things going on in the situation where you actually use this system. How about a modified sigwaitinfo that will return a number of waiting siginfo -- of course this introduces the problem of deciding how long to wait for new additions to the queue before returning. This is something similar to the Nagle algorithm.. Or perhaps sigwaitinfo could buffer siginfo's in user space, although this introduces complexity if you want the ability to cancel queued signals... Regards, Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message