scheduler event-types

[Roderic Morris]

I everyone, I'm planning to add a new event-type to s48's scheduling system that would allow users to block without contributing to deadlock detection (for instance, when waiting for an OS signal). I'd also like to write a scheduler that implements the narrowing event form the last scsh release, but without modifying s48 itself.

The second goal seems to be blocked by the fact that the event-types are a closed set. Is user code expected to use the upcall event, with some sort of token as the first argument to create their own events? I'll go forward with that solution if that's the case. I'm curious though; why are event-types are an enumeration, instead of just symbols or something similar?

-Roderic

[Roderic Morris]

Post by Roderic Morris
I everyone, I'm planning to add a new event-type to s48's scheduling system that would allow users to block without contributing to deadlock detection (for instance, when waiting for an OS signal). I'd also like to write a scheduler that implements the narrowing event form the last scsh release, but without modifying s48 itself.
The second goal seems to be blocked by the fact that the event-types are a closed set. Is user code expected to use the upcall event, with some sort of token as the first argument to create their own events? I'll go forward with that solution if that's the case. I'm curious though; why are event-types are an enumeration, instead of just symbols or something similar?

I wanna start this while I have some momentum, so I'll just use upcall. Hopefully someone who knows will find the time to answer this eventually.

-Roderic

[Will Noble]

Post by Roderic Morris
I everyone, I'm planning to add a new event-type to s48's scheduling system that would allow users to block without contributing to deadlock detection (for instance, when waiting for an OS signal).

I don't think we need a new thread event type to solve the problem of
waiting for an OS signal tripping the deadlock detection.

Right now you can block on IO, external events, or the alarm clock. Those
comprise three of the five asynchronous VM events. OS signal also belongs
in this category, but unlike the case for the other interrupts the root
scheduler can't know if any thread is waiting on a signal because the
responsible thread queue lives in the POSIX module. The runtime system
can't depend on the POSIX module being available.

At the same time, the POSIX signal system deals with both the numbered OS
signals known to the VM as well as the named POSIX signals, and maintains
a mapping between the two. It maintains signal queues for both kinds
of signals.

This suggests to me that we should move the signal queue system from POSIX
to the runtime, and let POSIX deal only with mapping between numbered
and named signals (for example it could still provide named-signal
queues). Then schedulers can query for the existence of threads waiting
on any kind of asynchronous VM event before giving up and announcing
deadlock.

Regards,
Will

[Will Noble]

(Correction to previous message: where I wrote "asynchronous VM events"
I meant "asynchronous VM interrupts".)

I looked at this some more and I've changed my mind. The current solution
maps signals queued by name to OS signal numbers on resumption, but leaves
signals queued by number alone, even if the number refers to a different
POSIX signal in the new system. This behavior would be hard to maintain
if we move signal queues and the interrupt handler to the runtime system.

That leaves keeping a count of threads waiting on signals, or keeping a
count of threads that promise to be waiting on some unspecified interrupt
(this is Roderic's proposal as I understand it).

Regards,
Will