• Logan Capaldo (23/23) Jul 10 2014 Apologies in advance if this belongs on the druntime forum, but
• Sean Kelly (15/36) Jul 10 2014 I'm not sure about portability of the realtime signals. Druntime
• Logan Capaldo (10/15) Jul 13 2014 I opened a pull request,

"Logan Capaldo" <logancapaldo gmail.com> writes:

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?

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

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)."

Thanks,
-Logan

"Sean Kelly" <sean invisibleduck.org> writes:

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.

"Logan Capaldo" <logancapaldo gmail.com> writes:

On Thursday, 10 July 2014 at 20:20:41 UTC, Sean Kelly wrote:
 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.

I opened a pull request, 
https://github.com/D-Programming-Language/druntime/pull/888. I am 
eager for any feedback. I ended up not having a thread_init2 sort 
of function as typically in this cases thread_init is going to be 
called indirectly via rt_init, and I didn't want to introduce 
several layers of XXXX2 functions to pass the parameters all the 
way down. If it is thought that is a better approach after all I 
am of course open to maing those changes.

Thanks.