Patching druntime to use different signals beside SIGUSR1/SIGUSR2?
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
Re: Patching druntime to use different signals beside SIGUSR1/SIGUSR2?
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 2 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.
Re: Patching druntime to use different signals beside SIGUSR1/SIGUSR2?
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.
