On Thursday, 5 March 2015 03:28:17 UTC-6, [email protected] wrote: > > > > 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. >
Ah, I forgot to mention! This doesn't happen when run with no JVM. I didn't consider that Matlab/JVM could be modifying the signal status during my MEX function but that's plausible and I wouldn't know if there's even a way to fix it. > > >> >> >>> >>> >>>> >>>> >>>>> >>>>> 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. > Argh, true. At least that's not required to get this in some working state. > > >> >> >>> >>> Don't underestimate any of those, especially for an opaque host like >>> Matlab. >>> >>> Cheers >>> Lex >>> >>
