Date: Mon, 8 Apr 1996 14:50:07 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, louie@TransSys.COM, msmith@atrad.adelaide.edu.au, roell@blah.a.isar.de, hackers@FreeBSD.ORG, jkh@time.cdrom.com, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604082150.OAA03046@phaeton.artisoft.com> In-Reply-To: <199604080223.LAA08178@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 8, 96 11:53:07 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. We have already decided that the mouse is highest priority. If you attempt to invoke muliple Real Time requirements, I'm going to say you might as well stop thee, since you are already screwed. The difference between doing a select() and always processing mouse events first vs. processing mouse events as data becomes available (which it won't, on polled devices -- you have to poll them, by definition, obviously) is that to reasonably process the events using select(), the time interval between select() loop calls has to be small enough. Thomas' problem is that he selects true, then processes a whole bunch of client events, to the exclusion of mouse events. To "fix" this, he wants to (potentially) process the mouse events on every return from a system call to user space -- ie: in a signal handler as a result of the trampoline code invocation. He says in other correspondance that he can't use pthreads because it uses SIGALARM and he needs to run an alarm timer on top of all the other tasks he's performing. Now I do know that going to a full state automaton with event virtualization will add *some* overhead, at the same time solving the problem. The question is the ratio of processing overhead required to keep up with the mouse events, which Thomas sees as having a realtime requirement. One potential fix is virtualizing the mouse device instead of the events in the server. This reduces the polling overhead in the "no mouse event" case, and you can fix Thomas' mouse synchronization problem by flushing buffers on correct (full data packet) boundries. > 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. Signals, once again, are not events. You will only respond efficiently to the first event in any sequence of events, then you will be screwed, since the signal won't be immediately reasserted (signals delivery is blocked one deep for active handler code, which means that if you get two events while processing a first event, you have just desynchronized the command stream. You can't say "read only 3 characters at a time, but read as many 3 character sequences as you can manage" to the tty driver running the mouse. This goes back to my suggestion of two years ago for a mouse line discipline (originally suggested to defeat FIFO's on mouse devices). > select() is good for multiplexing, and efficient processing of bulk data. > select() is _bad_ for rapid response to data. This is only true if the action you take as a result of the select() coming true are long duration relative to the desired response loop time. This has more to do with you not setting a state and returning to recall select(), falling back into the state processing for an active client than it does with any real inability to process the data in the require time frame. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604082150.OAA03046>