Fibers and inp()/outp() in Tango

[Sean Kelly]

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