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: 0 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 >> <https://github.com/JayKickliter/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 >> <http://www.fsf.org/blogs/community/free-software-in-space-gnu-radio-and-the-isee-3-spacecraft> >> >> 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 <https://github.com/bastibl/gr-ieee802-15-4.git> >> out-of-tree module for GNU Radio, but it's not complete and doesn't have >> the capability of de-spreading >> <http://en.wikipedia.org/wiki/Direct-sequence_spread_spectrum> 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) >> <https://github.com/JayKickliter/gr-juliaffi/blob/master/lib/juliablock_ff_impl.cc#L47> >> '. >> >> 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 >> <https://github.com/JayKickliter/gr-juliaffi/blob/master/lib/juliablock_ff_impl.cc> >> >> 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. >> >
