Re: Changeset 0306c5a64775
Robert Ransom <[email protected]> Sat, 7 Jan 2012 19:41:27 +0000
| Newsgroups | gmane.lisp.scheme.scheme48 |
|---|---|
| Message-ID | <CABqy+sqVbLwpwr4EuEgthSVNjqXeO975Z6L58rGRPhVOukoJWQ@mail.gmail.com> |
On 2012-01-07, Michael Sperber <[email protected]> wrote: > > Robert Ransom <[email protected]> writes: > >> Before Roderic's patch, waiting-for-external-events? didn't know that >> threads which were waiting on the process-id's placeholder were >> waiting for an external event, just as it still doesn't know that >> threads which are waiting on a signal queue are waiting for an >> external event. > > Why would it have to know that? In the process-id case, threads waiting on a process ID's placeholder are awakened by process-terminated-children, which is called by the os-signal interrupt handler. Nothing waits on an external-event UID. In the signal-queue case, threads waiting on a signal queue's ready-for-read condvar are awakened by the os-signal interrupt handler pushing a signal object into the signal queue. Nothing waits on an external-event UID. If the deadlock-detection code isn't told that those synchronization objects will be alerted by (an interrupt handler triggered by) an external event of some sort, then it will falsely report that a deadlock has occurred. > And, even it were necessary to know > that, it would be easier to look at the condvar's waiters instead of > marking the queues, no? No, because we also need to look at placeholders' waiters, and the simplest way to handle both condvars and placeholders (as well as other synchronization ‘primitives’ which may be added in the future) is to look at their underlying thread queues. > I still feel I'm missing something important in your argument ... > >> Regarding getaddrinfo, I think the Right Thing is to make the Scheme >> interface to getaddrinfo fill in a placeholder, rather than using the >> external event system directly as it does now. > > OK - it still seems to me the hard part is communicating the information > from C to Scheme somehow. > > But at this point I really just want to fix the deadlock issue and the > potential bug before the release (which I really, really want to happen > soon). After that, we can make bigger changes. The interrupt system has been slightly broken for as long as I nave used Scheme 48, and I haven't figured out why. I think not using interrupts in a way that will definitely trigger that brokenness (i.e. not flooding it with multiple interrupts of the same type at once) is sufficient for the release. Robert Ransom