Fibers and inp()/outp() in Tango
Sean Kelly
sean at f4.ca
Tue Aug 28 18:37:08 PDT 2007
Ingo Oeser wrote:
> Sean Kelly wrote:
>> Ingo Oeser wrote:
>>> Sean Kelly wrote:
>>>
>>>>> BTW: I see Unix signal handling is widely ignored in tango, is that
>>>>> true?
>>>>> I can imagine why.
>>>> Tango uses signals to coordinate garbage collection, but that's about
>>>> it. I think signals are quite useful in some instances, but they're too
>>>> limited and too expensive to be a general-purpose tool.
>>> Yes, but they need to be considered in the threading design AFAIK. I can
>>> dig out more details, if you like. But I still don't know exactly, how
>>> threading in D and Tango is supposed to behave in the presence of signal
>>> (e.g. : Which thread get which signals?).
>> This may be a result of my ignorance of Unix here. I have made an
>> effort to handle signal-related interruptions of thread routines, but
>> wasn't aware that there is a way to specify which thread handles which
>> signals.
>
>> SIGUSR1 and SIGUSR2 are reserved for use by the GC,
>
> Is that documented somewhere?
I don't think so, though it should be.
> Can that mechanism be changed to not require signals?
Not that I know of. Basically, the GC needs some way to suspend threads
while performing a collection. On Unix, this is typically accomplished
by sending each thread a signal to tell it to wait, and another to tell
it to resume. Windows has actual suspend/resume operations as a part of
its debug routines.
> How do you prevent blocking these signals?
If the user defines their own signal handler for SIGUSR1 or SIGUSR2 then
garbage collection will simply break. I don't know of a good way to
enforce this.
> These are usually used for userland stuff (like trigger logging/debugging).
>
> What about using POSIX RT-signals for that, if signals are required there?
>
> These POSIX reliable signals are ORed together in a pending mask
> and their order of delivery is undefined, while they are blocked.
>
> So using SIGUSR1 for suspend and SIGUSR2 for resume might not work.
> The early LinuxThreads implementations made the same mistake.
I was pretty careful with how the mechanism works, and it seems
reliable. Semaphores are actually used to communicate between the
signal handler and the GC thread.
> So one usually handles signals in the main thread and block all
> blockable signals in all other threads. That is safest.
> Signals are not really designed for threads :-/
pthread_kill is though, I would hope.
Sean
More information about the Digitalmars-d
mailing list