On Thursday, March 5, 2015 at 3:24:28 PM UTC+10, Eric Davies wrote: > > > > 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. >
Right, I wonder if Matlab or the JVM is modifying signal status in another thread whilst Julia is running, and that is being overwritten by the restore. And IIUC the JVM uses signals as part of its GC process, can you try running Matlab with no JVM. If you knew what Julia set the actions to, you could check that they are the same when you come to restore them. But Julia just uses signal() and I don't know what that sets masks and flags to. > > >> >> >>> >>> >>>> >>>> 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. > AFAIK Python doesn't try to poll IO anywhere but the subprocess module, but it has been a while since I looked. Its really only the three FDs that are shared I would be concerned about. > > - 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. > If Julia guarantees to catch all exceptions thats fine :) > >> - 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 :) > Hopefully this is the easy one, or at least, its all under Julia control so its "only" a matter of effort :) > > >> >> - 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? > The C calling is fine, but remember that all the things mentioned above have to be set back the way the Matlab code you are calling expects them to be. And any Matlab exceptions need to be changed to Julia ones on return. > > >> >> Don't underestimate any of those, especially for an opaque host like >> Matlab. >> >> Cheers >> Lex >> >
