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 <jay.kickli...@gmail.com> 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 <jay.ki...@gmail.com> 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: > 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 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.
