Date: Mon, 8 Apr 1996 11:53:07 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: terry@lambert.org (Terry Lambert) Cc: louie@TransSys.COM, msmith@atrad.adelaide.edu.au, roell@blah.a.isar.de, terry@lambert.org, hackers@FreeBSD.ORG, jkh@time.cdrom.com, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604080223.LAA08178@genesis.atrad.adelaide.edu.au> In-Reply-To: <199604071939.MAA00383@phaeton.artisoft.com> from "Terry Lambert" at Apr 7, 96 12:39:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying: > > > While not an X server application, you'll note that xntpd uses SIGIO > > so that it might read and, most importanty, timestamp traffic arriving > > on the network. This is critical to making NTP accurately synchronize > > the clock. By using SIGIO, you can not have to worry nearly so much > > about long-running sections of code and not being able to check for > > pending input for a "long" time. The model of signal as 'interrupt' > > works extremely well for this sort of appliation. Of course, this all > > works Just Fine with sockets.. > > Signals are not events. What is wrong with select() that makes it > unsuitable for your use? The point is that as soon as the process involved runs again, its signal handler runs, effectively overriding any internal scheduling it is performing using select(). Imagine that you are using select() to watch several stream connections, and a large body of data appears on one. You bounce off and digest as much of it as possible, in the name of efficiency. This may take some time, and while you are doing it, you _won't_ be selecting on the other streams. So if one of these other streams wants attention, you lose. However, if you can get a signal when it wants attention, you can spend as long as you like being efficient with your bulk data, and still respond in a timely fashion to events that require it. select() is good for multiplexing, and efficient processing of bulk data. select() is _bad_ for rapid response to data. SIGIO is a convenient (but not necessarily appropriate) alternative that would be _bad_ for bulk data, but good for handling asynchronous arrival of exceptional data. > So it's not like you get increased response time or anything. Ah, but you do. It's just that you're thinking of the wrong scheduler. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604080223.LAA08178>