Not sure it will help your specific use case, but see http://docs.julialang.org/en/release-0.3/manual/calling-c-and-fortran-code/#thread-safety and an example in https://github.com/JuliaGPU/CUDArt.jl/blob/master/src/stream.jl
--Tim On Wednesday, June 17, 2015 12:29:18 AM [email protected] wrote: > I need to call "waitformultipleobjects" (windows equivalent of "select" > call in linux) from julia using ccall. As this is a blocking function, I > would like to call it within another coroutine (task). > > > > The problem is that the “Taks” in Julia only function effectively if all > the blocking calls within it emanates from julia's own I/O interface. It > cannot deal with any blocking call to native C-functions. > > > > As far as I can see julia is based on Libuv. I guess every time a blocking > call (from defined I/O interface) is issued, julia internally calls a > corresponding function from the asynchronous libuv and then waits() for a > notify() from the libuv. I guess the entire scheduler of julia is based on > this paradigm so that It can deal with asynch operation within a single > thread. > > > > My question is, is it possible to extent this wait() - notify() paradigm > for any arbitrary blocking ccall call? > > > > I have tried the following solution, but it fails miserably: > > 0) Start a task which calls a non-blocking function from the dll and then > wait() for a notify(). > 1) (In C) Implement a dll which creates another thread to call the real > blocking function whenever julia calls the non-blocking function in the > previous step. > > 2) Provide a Julia callback function to the dll which is called at the > finalizing step of the thread by the dll. > > 3) (In Julia) the callback function calls the notify() function. > > However, it turned out that notify() function itself is not thread safe and > Julia’s respond to notify() from another thread (created in C) is totally > random. > > Is it possible to make the julia’s scheduler handle the arbitrary blocking > calls? > > > > (PS: I was previously advised a solution based on parallel processes. > However, for several reasons, multi-process paradigm is not a suitable > option for me right now.)
