Date: Sun, 7 Apr 1996 12:35:25 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, roell@blah.a.isar.de, hackers@FreeBSD.ORG, jkh@time.cdrom.com, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604071935.MAA00369@phaeton.artisoft.com> In-Reply-To: <199604071247.WAA06437@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 7, 96 10:17:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> No, this is _not_ the correct question. The question is "how can I arrange > to receive a signal (eg. SIGIO) when there is data to be read on a > descriptor, without making it the controlling TTY." > > The answer is "you can't, without using a coprocess." This is a shame, > however bde has provided some reasons as to why this currently isn't > possible. Actually, this is quite possible; the process which does the open in this case is the sole openenr and never changes. There really no reason that the PID shouldn't be pulled from the tty struct for the gsignal. Of course, since signals are persistent conditions, not events, it is pretty useless to try to use signals for anything, and it is only tolerated for SIGCLD because you can poll for child exit status with a rich enough wait*() abstraction. > Er, almost certainly not. Try "low-cost asynchronous input". Remember > what TR does? Think about how handy it would be to do your mouse data > handling inside a signal handler; your main loop would be presented > with events out of a FIFO as faits accompli, you could probably even > stuff the location registers in the signal handler. > > From my (naive) viewpoint, it would sure beat the hell out of using select(), > which has alreaby been stated is the _current_ way of doing it. I give up. Why is this the case? What is wrong with select()? 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?199604071935.MAA00369>