On Wednesday, 4 March 2015 20:15:31 UTC-6, [email protected] wrote: > > > > On Thursday, March 5, 2015 at 10:16:30 AM UTC+10, Eric Davies wrote: >> >> >> >> >>> 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. >>> >> >> This is not sufficient, so maybe something else is going wrong, or I'm >> not doing it right. It's not that expensive if you're not calling Julia >> very often (and not for my purposes). >> > > Fair enough, note your gist doesn't show you saving and restoring any > sigactions, can you post the version where you try to do that? >
Right, gist now updated with the signal-handling file. > > >> >> >>> >>> 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. >>> >> >> I would agree, but the Julia devs appear to want to make embedding >> possible, so that effort may be available. In any case, the overhead of >> having to program the communication on both ends is a factor in addition to >> performance. >> > > Indeed the communication coding and runtime overhead is an issue, but it > needs to be weighed against issues like: > > - IO sharing, Julia/libuv and the host cannot both do a select/poll on the > same FDs (eg stdin, stdout, stderr) > Admittedly I don't fully understand this. Regardless, PyCall doesn't handle this and it has been very popular. - error/exception handling, preventing them escaping from Julia and/or > raising a host exception/error instead > This is actually wonderfully easy with the Julia API! One can just check `jl_exception_occurred()` after a call and then throw a MATLAB exception if something happened. > > - signals sharing (as in the OP) > > - making sure all the process state is restored when Julia exits, eg > rounding modes > Rounding modes can be handled pretty easily, and I'm fairly confident we can deal with new things as they pop up. At this point I just want a non-crashing version of what I have at the moment, which is pretty good! > > - the opposite of the above, making sure Julia sets up the process state > fully, not assuming its a new default process > This is definitely harder. But this is a goal for the Julia project given that embedding is a goal :) > > - callbacks into the host, best to forget about that for now :) > I can't imagine it would be that hard to write C callbacks given all the other interop work that will have already been done. But perhaps I'm naive? > > Don't underestimate any of those, especially for an opaque host like > Matlab. > > Cheers > Lex >
