Date: Mon, 8 Apr 1996 15:01:34 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: roell@blah.a.isar.de (Thomas Roell) Cc: terry@lambert.org, roell@blah.a.isar.de, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG, jkh@time.cdrom.com, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604082201.PAA03075@phaeton.artisoft.com> In-Reply-To: <199604081003.MAA00330@blah.a.isar.de> from "Thomas Roell" at Apr 8, 96 12:03:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I think you don't get it. The problem is no matter what I do, select() > will be only called rarely, which means that a pipe would not help at > all. Increasing the buffer size by any means just moves the problem to > a different threshold, rather than solving it. It seems you have five options: 1) Use pthreads (SIGALARM problem, from private email) 2) Use another process 3) Change your code to use subautomatons and call select() less rarely. 4) Assume SIGIO works like an event instead of a signal (it doesn't). 5) Pray for a miracle. > Just another example. We are (aehm from the sales prespective will be) > supporting HW-MPEG playback. The MPEG chip is fed with data > asynchronously via periodical SIGALARM calls. It is easily possible > that depending upon your bitstream, that for a while the X-Server will > not get back to the select() at all. It should get back up anway by setting a state variable an intentionally dropping out to allow select() to be hit, if you are using select() as your primary event source. If not, refer to #4 above. > > Well. It seems that you really want a fix in another area of BSD, > > and that this fix is just a software fix to the fact that the other > > area is broken. 8-). > > What I want is being able to open multple /dev/ttyd* devices and get a > SIGIO if there is new input available. Say you can do this. How do you know which device generated the SIGIO -- or do you care? You can't assume you can reliably do many types of processing in a signal handler, other than to set a volatile flag that you later examine (like at the top of your select() loop). Signals are bogus. 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?199604082201.PAA03075>