Re: Changeset 0306c5a64775

On 2012-01-11, Will Noble <[email protected]> wrote:
> On Tue, Jan 10, 2012 at 10:11:26AM +0000, Robert Ransom wrote:
>> On 2012-01-08, Will Noble <[email protected]> wrote:
>> > This suggests to me that the RTS should at least keep track of the
>> > number of
>> > threads waiting for a signal, and POSIX could increment/decrement that
>> > number. Then there could be a function WAITING-ON-OS-SIGNAL? that
>> > ROOT-WAIT
>> > could check.
>>
>> Would a counter be sufficient for this?  I see some use of weak
>> pointers in scheme/posix/signal.scm, so I really have no idea whether
>> we could safely use that optimization (i.e. look at a counter instead
>> of the thread queues themselves), even if we didn't need a more
>> general solution.
>
> Yes. A sleeping thread can't wait for a signal so a counter works just as
> well as looking at the thread queue. It's less optimization than
> convenience. With the approach I outlined in the previous message you might
> equally well register the actual thread queues with the RTS and have
> ROOT-WAIT go through them to see if a thread somewhere is waiting for a
> signal, but a counter does the same thing.

???  A thread which is waiting for a signal is sleeping.  In any case,
I don't see how this is relevant to whether we can use a counter
(which will break deadlock detection permanently if one of the signal
system's thread queues is ever GCed while a thread is blocked on it)
to determine whether any threads are waiting for an OS signal.

> Regarding the weak pointer usage in signal.scm: those map signal numbers to
> signal representations. If, say, you have a signal 5 in the system, the
> mapping returns the existing object when asked for signal 5. However, if
> everyone else loses their reference to that object, you don't want the
> abstract concept of "5" to keep it around forever without being
> garbage-collected. It's not something that would break the counter shortcut.

Signal queues are weakly held too.  Fortunately, the
(signal-queue-signals queue) call in find-next-signal keeps a
reference to the signal queue around when a thread is blocked on the
queue, so we would get away with the counter optimization (but only by
a lucky accident).


Robert Ransom