Re: Changeset 0306c5a64775

On Sat, Jan 14, 2012 at 12:43:53PM +0000, Robert Ransom wrote:
> ???  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.

I misunderstood your issue with the counter and ended up explaining why we
couldn't double-count, which is incredibly obvious. I hope you were not
offended ;). On the other point, it doesn't look to me like a thread queue
with a thread in it waiting for a signal could be garbage-collected...

> 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).

...although I don't understand how this prevents it. The mechanism I see is
the signal mapper (from OS signal number to list of thread queues, for all
known signals). It strongly references every non-empty thread queue. So a
way to know if any thread is waiting for a signal without keeping a counter
is to iterate over the mapper looking for a non-empty queue.

(Also evidently I was talking about a different usage of weak pointers in
signal.scm than the one you referred to, so basically my entire post
explained the wrong things. Sorry!)

I don't think we really have a disagreement here. To summarize my
recommendation, I like the narrow solution where the deadlock detection code
checks if any thread is waiting on an OS signal; currently it doesn't take
this into account at all. POSIX has the relevant information, but we need it
to call the RTS instead of the other way around to avoid making the RTS a
client of POSIX. We could accomplish this a number of ways, including using
a counter.

Best,
Will