Re: usr1-signal, usr2-signal, etc.

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Tue, 12 Dec 2006 10:47:09 +0100, storm@cua.dk (Kim F. Storm) said:

> What if the signal handlers just increment a global counter (one for
> each signal type), and the main loop in keyboard.c checked those
> counters and added the pending signal events in the "safe context"?

There're two problems I can think of with this approach.

First, it will cause a race condition.  I guess the global counters
will be checked just before `select' is called in
wait_reading_process_output.  But if SIGUSR1 is delivered between the
check of the counters and the call to `select', it does not interrupt
`select' and will not be noticed until another input/signal becomes
available or the timeout expires.  This issue is discussed in [1].

Second, the current `select' emulation code in the Carbon port does
not wait for signals, but only for window system events and process
outputs via sockets.

In principle, both of them can be solved by converting signal delivery
to data delivery on a pipe or a UNIX domain socket as in [1].  But
this will require not-so-small changes, and I fear this becomes
another sit-for case.

Is it possible to postpone this feature to after the release?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[1] Unix Network Programming, Volume 1: The Sockets Networking API,
3rd Edition, Chapter 20, Section 5.