Patching druntime to use different signals beside SIGUSR1/SIGUSR2?

[Sean Kelly via Digitalmars-d]

On Thursday, 10 July 2014 at 19:54:28 UTC, Logan Capaldo wrote:
> Apologies in advance if this belongs on the druntime forum, but 
> it seemed to be full of exclusively automated posts?
>
> I'm looking to integrate D into an existing code base. So far 
> so good, but I'm concerned that the relatively rare but 
> non-zero use of SIGUSR1/SIGUSR2 in the code base will, due to 
> murphy's law bound to trip something up and put people in a 
> position of having a confusing and difficult to debug issue. 
> Fortunately we _do_ have a centralized "allocator" for Posix 
> realtime signals. I was thinking of adding a int rt_init2(int 
> suspendsigno, int resumesigno) function (not looking to 
> bikeshed on the name/arguments at the moment, if people find 
> this reasonable/useful I will happily have that discussion) as 
> an alternative to rt_init(). My questions are basically:
>
> 1) I can't think of any reason something would break by making 
> this configurable, but I could be mistaken. is there?

I'm not sure about portability of the realtime signals.  Druntime
is built against maybe not the most recent POSIX spec, so I'd
want to verify that.  Or we could make the signal used
platform-dependent, so our best effort would be to not use
SIGUSR1/2, which I guess is what you were getting at by making it
configurable.  No code would be broken if the signal changed
though.  This is all isolated within core.thread.


> 2) Is rt_init() the right sort of function, or should it be at 
> thread_init time?

I think thread_init is the correct place.  That's where the
signals are set today.


> 3) Is there an existing effort in this direction? I tired 
> searching around, but mostly just found evidence that "yes, 
> druntime uses sigusr1/sigusr2 as part of the gc implementation 
> on !(windows, osx)."

Not currently.  Mostly because you're the first person to run
into this issue (or at least to ask about it, as far as I can
recall).  Using signals for collection at all is a real sore
point for me--I think it's a terrible but necessary hack--so any
improvements that can be made regarding this are welcome.