Fibers and inp()/outp() in Tango

[Ingo Oeser]

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? Can that mechanism be changed 
to not require signals?
How do you prevent blocking these signals?

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.

> and the rest just go where they may. 
> I think the main thread may always be the recipient of kill() signals?

This article makes quite a good reference on that topic:
http://www.linuxjournal.com/article/3985

Many of that noted Linux bugs are fixed now, but for an exact state,
I would have to ask on linux-kernel.

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 :-/

>> BTW: I noticed in horror, that tango.sys.Process doesn't provide fork.
>>         You cannot do this to the Unix guys :-)
> 
> I'll pass that on :-)

Many thanks! 

fork() is required to change sth. like the "security context" [1] 
under Unix.


Best regards

Ingo Oeser

[1] Yes, that is inexact, but closest to the Windows terms :-)