[MLton] Re: Signal Handlers in multiMlton

[Daniel Spoonhower]

Hi, MLton developers.

KC and I have been having a conversation that was initially pretty
specific to my initial multiprocessor implementation, but has drifted
toward something that might be of more general interest.  Start from the
bottom if you want to follow along.

KC: just one small comment, inline, below.

--spoons

Sivaramakrishnan KC wrote:
> Daniel Spoonhower wrote:
>> My (limited) understanding of signals leads me to think that the signal
>> should be delivered to exactly one thread.  
>>
> That is correct.
>
>> In my version of things,
>> there is no way to set signals differently for different pthreads (as
>> pthreads are not exposed to the programmer) so it wouldn't matter which
>> thread handled it.  Perhaps you have different needs, however.
>>
>>   
> I might. For parallelizing CML, I would like to run preemptive
> schedulers for threadlets on top of every pthread. Apparently, the
> interval timers are shared between the pthreads of a process. So I am
> planning to deliver the alrm signal to every gcstate when I get it.
>
>> So as for how to find the correct gcState, I'm not sure.  One strategy
>> would be to set the signalIsPending flag for all pthreads and set the
>> limit pointer to zero for those that with atomicState == 0.  Each thread
>> would then try to enter() wait for the global runtime lock.  (A new
>> check would be needed in ensureHasHeapBytesFreeAndOrInvariantForMutator
>> to force threads to do an enter() when a signal is pending.)  The first
>> thread through the barrier that was waiting for that signal could then
>> set up a handler to be run after leave().  This is the easiest way I can
>> see to accomplish this, but perhaps it is too expensive.
>>
>>   
> Yes. Since signals are delivered to exactly one thread in C (and not
> necessarily to the thread that generated it), I could just look up
> signalsInfo.signalsHandled for every gcState and find a thread that is
> registered to receive the signal and set its flag and limit. That way
> we'd have the same behavior as C.
>

That sounds reasonable to me.  There is, however, already a layer of
multiplexing happening in basis-library/mlton/signal.sml, so this would
add an additional (and perhaps necessary) layer.

>> Having written all of that, it occurs to me that I've never tried to
>> call pthread_getspecific inside of a signal handler.  Maybe that will
>> work?  If it does, you could zero the limit of only that thread, and
>> then look for signals in maybeSatisfyAllocationRequestLocally (and avoid
>> the big runtime lock).
>>
>>   
> Sadly, calling pthread_getspecific() inside the signal does not get the
> correct gcState.
>
>> --spoons
>>
>>
>>   
> - kc.
>> Sivaramakrishnan KC wrote:
>>  
>>> I've made some headway into getting signal handling in multicore mlton.
>>> I have made the global data structures in signals.sml, threads.sml and
>>> Posix/signal.c, local for each thread. But I haven't been able to get
>>> around the problem of getting the correct GC_state after the signal is
>>> handled. One possible work around is to deliver the signal to all the
>>> pthreads that have registered to receive the signal and not currently
>>> masking it. This is not as bad as it sounds because when multiple
>>> threads are registered for a particular signal in a process, the signal
>>> is delivered to any one of the thread. We'd just be delivering the
>>> signal to all of the threads. Or we could deliver the signal to any one
>>> such thread.
>>>
>>> so Is there a way to get the correct GC_state after a signal is handled?
>>>
>>> And, the regression tests that had been failing because of signals, now
>>> work on a single core.
>>>
>>> Daniel Spoonhower wrote:
>>>    
>>>> The short answer is that I didn't need signals, and I was trying to
>>>> make
>>>> the smallest set of changes (especially since I was learning how the
>>>> MLton runtime worked).
>>>>
>>>> One obstacle to getting signals working is that basis/Posic/Signal.c
>>>> uses the symbol gcState frequently.  In the trunk of MLton, this refers
>>>> to a single, global data structure.  In multiMLton, there is one
>>>> GC_state structure per pthread (accessed via thread-local state) so
>>>> some
>>>> work would have to be done to get a handle on the correct GC_state
>>>> after
>>>> a signal is handled.
>>>>
>>>> Another problem is that some of that code assumes it is run in a
>>>> critical section.  In the trunk this is accomplished using
>>>> MLton.Thread.atomic*.  In multiMLton, these functions only guarantee
>>>> atomicity on a given pthread, not global atomicity.  In multiMLton,
>>>> global critical sections are created in the runtime using enter and
>>>> leave (or the macros ENTER* and LEAVE*).
>>>>
>>>> Beyond that I haven't looked too much into signals.  If you can figure
>>>> out what needs to happen, I can help you make it work in multiMLton.
>>>>
>>>> --spoons
>>>>
>>>> Sivaramakrishnan KC wrote:
>>>>  
>>>>      
>>>>> Hey
>>>>>
>>>>> Is there a reason why signal handlers are not yet supported in
>>>>> multiMlton? What would have to be done to support signal handlers?
>>>>>
>>>>> Thanks
>>>>> kc
>>>>>
>>>>>             
>>>     
> 
>