This is a hard problem to solve generally, in another context I worked on, 
it took a huge amount of effort to embed (in the same process) a previously 
standalone language whose runtime assumed it had sole use of all resources.

I don't have Matlab so I can't try anything, but as a general comment I 
would say that if Julia is going to support embedding in the same process 
it has to cooperate with its host on usage of shared resources like 
signals.  If Julia is simply initialized, runs some code, shuts down and 
returns then saving the sigactions before jl_init and restoring the 
sigactions after Julia shuts down (and before returning to Matlab), for all 
signals Julia uses, should be sufficient, but initializing and shutting 
down each time is expensive.

If Julia is to remain initialized then for signals it probably should add 
its actions as Tim pointed out, keeping the old action and, when a signal 
occurs, do something like:

   if in_a_Julia_function then do Julia handler
   else do host action

Of course this doesn't help if Matlab then changes the sigaction again.  As 
its not open its not possible to know if this happens.

So in the end it may turn out to be more effective to run Julia in another 
process communicating via shared memory. That would probably (unbenchmarked 
of course :) be better performing than re-initalizing Julia every time a 
piece of Julia code is run.

Cheers
Lex

On Thursday, March 5, 2015 at 8:51:19 AM UTC+10, Eric Davies wrote:
>
> It appears as if that did not solve the problem, though I verified that it 
> did what was intended. This is unfortunate. I'll continue looking at this 
> for a day or two but I'm not confident I can find a solution alone. Here is 
> a minimal set of code to replicate: 
> https://gist.github.com/iamed2/e883c6b0b8ff4220d946
>
> On Wednesday, 4 March 2015 06:06:19 UTC-6, Tim Holy wrote:
>>
>> It seems possible we should add a second "boolean" argument to 
>> _julia_init (in 
>> init.c) that controls whether the signal handlers get set. But as a 
>> workaround: 
>>
>> http://stackoverflow.com/questions/9495113/how-to-get-the-handlers-name-address-for-some-signals-e-g-sigint-in-postgres
>>  
>>
>> You could at least test whether that solves the problem, and then if so 
>> perhaps it would be worth opening an issue in julia about whether we need 
>> a 
>> better solution. 
>>
>> BTW, I'm interested in this topic too; see also 
>> https://groups.google.com/d/msg/julia-users/dP_J5KilsEs/4CIERQ14vdgJ. We 
>> should collaborate on a single solution (and it sounds like you're 
>> farther 
>> along and perhaps more invested). I'm happy to pitch in if code gets 
>> posted 
>> somewhere. 
>>
>> --Tim 
>>
>> On Tuesday, March 03, 2015 09:18:04 PM Eric Davies wrote: 
>> > Hi all, 
>> > 
>> > I'm attempting to embed julia in a MATLAB MEX file. Everything is going 
>> > great, but MATLAB will sometimes segfault after having run some code 
>> > calling Julia.* I believe I have narrowed it down to this 
>> > issue: http://ubuntuforums.org/showthread.php?t=2093057 . Basically, I 
>> > believe Julia is registering a SIGSEGV (or maybe other signal?) handler 
>> > that overwrites the default for the JVM set by MATLAB. after the Julia 
>> > function is done, that memory is freed. Then a segfault (or maybe other 
>> > signal?) happens in the JVM and it tries to call Julia's handler but 
>> > segfaults (again) as it is no longer there. 
>> > 
>> > Can anyone help me find a workaround? Perhaps if there's a way to 
>> > "deregister" the handler, or if someone knows a way to get the current 
>> > handler (before calling into Julia) and then setting it back to that 
>> after 
>> > Julia is done. 
>> > 
>> > I've never dealt with signals in C before so I apologize if I'm 
>> describing 
>> > things incorrectly or missing something. 
>> > 
>> > Thanks, 
>> > Eric 
>> > 
>> > *I am able to reliably reproduce this by running any MEX function 
>> linking 
>> > to Julia and calling jl_init, then calling `help clear` in MATLAB. 
>> > 
>> > P.S.: I'm on Mac OS X 10.10 with MATLAB R2012b and Julia 
>> v0.3.6/v0.4.0-dev 
>>
>>

Reply via email to