For now can you just wrap all your libjulia access in a shared mutex on the wrapper side? Obviously you'll lose the benefits of parallelism while you're in Julia land, but it beats a segfault.
-s On Tue, Apr 21, 2015, at 09:46 AM, Jay Kickliter wrote: > Yes, you can run in separate processes and pipe data over ZeroMQ. > That's how I was using testing my Julia DSP code before writing this > block. It's not very convenient though. > > When thread safety is here and I call libjulia from two different > threads, will one block the other? Will it be possible to instantiate > two Julia contexts in one process? > > On Tuesday, April 21, 2015 at 12:17:32 AM UTC-6, Viral Shah wrote: >> Multi-threading is still some ways away - but thread safety is slowly >> falling into place. Is running in separate processes a possibility >> with GNU Radio for now - with some forking? >> >> >> -viral >> >> >> >> >> > On 21-Apr-2015, at 1:47 am, Jay Kickliter <[email protected]> >> > wrote: >> >> > >> >> > Thanks Jameson. I've read that Julia was working on threading, >> > but in my naiveté I didn't think that applied in this context. >> > It really limits this usefulness of this project. Generally I'm >> > only working on one custom block at time, and can probably work >> > around it. >> >> > >> >> > On Monday, April 20, 2015 at 1:42:06 PM UTC-6, Jameson wrote: >> >> > Julia doesn't pay any attention to threading (currently), so it'll >> > try to run all of those thread units in the same address space and >> > just generally not work (repeated calls to jl_init are no-ops). >> >> > >> >> > On Mon, Apr 20, 2015 at 3:38 PM Jay Kickliter <[email protected]> >> > wrote: >> >> > Viral, you might be able to answer this one. In GNURadio, every >> > block runs in its own thread. When I have two julia blocks, each >> > running in separate threads and calling jl_init, should that cause >> > a problem? It seems to work fine when I run a quick unit test, but >> > crashes hard when actually running flow graph with indefinite >> > number of samples. It also seems to crash right away. These parts >> > of the crash log stick out: >> >> > >> >> > Thread 24 crashed with X86 Thread State (64-bit): >> >> > rax: 0x458b1063894c0873 rbx: 0x00007f9158d09960 rcx: >> > 0x000000012c499ff8 rdx: 0x000000012c431ff8 >> >> > rdi: 0xffffffffffffe001 rsi: 0x0000000000001fff rbp: >> > 0x000000012c8bf420 rsp: 0x000000012c8bf2f0 >> >> > r8: 0x0000000000001fff r9: 0x0000000000001fff r10: >> > 0x00007f9158d09930 r11: 0xffffffffffff8008 >> >> > r12: 0x00007f9159dab820 r13: 0x0000000118f17800 r14: >> > 0x00007f9158d09930 r15: 0x00007f9158d09960 >> >> > rip: 0x0000000118239b41 rfl: 0x0000000000010246 cr2: >> > 0x000000012c431000 >> >> > >> >> > >> >> > >> >> > Thread 24 Crashed: >> >> > libjulia.dylib 0x0000000118239b41 jl_call2 + 273 >> >> > 1 libgnuradio-juliaffi.dylib 0x00000001181b11f8 >> > gr::juliaffi::juliablock_ff_impl::general_work(int, >> > std::__1::vector<int, std::__1::allocator<int> >&, >> > std::__1::vector<void const*, std::__1::allocator<void const*> >&, >> > std::__1::vector<void*, std::__1::allocator<void*> >&) + 200 >> >> > 2 libgnuradio-juliaffi.dylib 0x00000001181b127e non-virtual thunk >> > to gr::juliaffi::juliablock_ff_impl::general_work(int, >> > std::__1::vector<int, std::__1::allocator<int> >&, >> > std::__1::vector<void const*, std::__1::allocator<void const*> >&, >> > std::__1::vector<void*, std::__1::allocator<void*> >&) + 78 >> >> > 3 libgnuradio-runtime.3.7.6.1.dylib 0x0000000110ac00f3 >> > gr::block_executor::run_one_iteration() + 2151 >> >> > 4 libgnuradio-runtime.3.7.6.1.dylib 0x0000000110aff8f9 >> > gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr<gr::block>, >> > int) + 2461 >> >> > 5 libgnuradio-runtime.3.7.6.1.dylib 0x0000000110af6544 >> > gr::tpb_container::operator()() + 74 >> >> > 6 libgnuradio-runtime.3.7.6.1.dylib 0x0000000110af6354 >> > gr::thread::thread_body_wrapper<gr::tpb_container>::operator()() + >> > 26 >> >> > 7 libgnuradio-runtime.3.7.6.1.dylib 0x0000000110ab2976 >> > boost::function0<void>::operator()() const + 28 >> >> > 8 libboost_thread-mt.dylib 0x0000000110e76d05 boost::(anonymous >> > namespace)::thread_proxy(void*) + 133 >> >> > 9 libsystem_pthread.dylib 0x00007fff8eb9a268 _pthread_body + 131 >> >> > 10 libsystem_pthread.dylib 0x00007fff8eb9a1e5 _pthread_start + 176 >> >> > 11 libsystem_pthread.dylib 0x00007fff8eb9841d thread_start + 13 >> >> > >> >> > >> >> > On Monday, April 20, 2015 at 10:10:54 AM UTC-6, Viral Shah wrote: >> >> > This is really cool. I had heard about GNU Radio, and now this is a >> > good excuse to learn a bit more about it. :-) >> >> > >> >> > -viral >> >> > >> >> > On Monday, April 20, 2015 at 7:52:51 PM UTC+5:30, Jay Kickliter >> > wrote: >> >> > I just pushed a rough draft gr-juliaffi to GitHub. It is not a >> > Julia package, but a GNU Radio module (C++/Python) that calls your >> > Julia code to do the actual signal processing. >> >> > >> >> > If you're not familiar with GNU Radio, it is a software defined >> > radio (SDR) framework. SDR is really cool. Traditional radio >> > hardware is dedicated to certain kind of signal (like a satellite >> > modem or FM receiver). SDR lets you use generic hardware that does >> > little more than digitize the raw radio waves and send them to a >> > computer. From there, all the signal processing is performed in >> > software. There are real world applications of SDR. I use it almost >> > every day. >> >> > >> >> > The motivation for this block came recently when I needed something >> > GNU Radio didn't have yet. At my job, we're developing new 802.15.4 >> > hardware. There is an 802.15.4 out-of-tree module for GNU Radio, >> > but it's not complete and doesn't have the capability of >> > de-spreading 802.15.4 900 MHz BPSK signals. I wrote code to >> > de-spread the signal in Julia, and piped from/to GNU Radio using >> > ZeroMQ. That works fine, but it's cumbersome. Why not just have GNU >> > Radio call the Julia code directly? >> >> > >> >> > If you do want to use the module, please let me know what issues >> > you run into when building/using it. I spent two solid days just >> > trying to get cmake to find and properly set up linking to >> > libjulia. I'm using OS X, and @rpath was causing the biggest >> > problem for me. It only built when I finally stopped trying to tell >> > cmake where to find libjulia and switched to find_library. Also I >> > had to do an actual `make install release` in the Julia repo for >> > all the headers and libraries to be in predictable locations. >> > That's because the FindJulia cmake module I added calls julia on >> > the command line to figure out where stuff is. The code still >> > crashes if I try to run it with `jl_init(NULL)'. >> >> > >> >> > There's still more c++ work to be done, and I don't know c++. I >> > just infinite monkey it 'till it works. I just hope I or someone >> > else can figure out how to make the c++ configure itself >> > dynamically, so it isn't necessary to define blocks for every combo >> > of input/output type. Most of the repo was automatically created >> > with gr_modtool. This file is pretty much the whole project. It's >> > definitely possible to change the number of inputs/outputs to block >> > at runtime. Looking at the code, I think it may be possible to >> > change the type as well. >> >> > >> >> > I was hoping have this done with some good examples in time to give >> > a JuliaCon talk. Maybe next year. I'll be there anyway, if anyone's >> > interested I'll give an informal demo. >>
