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] > <javascript:>> 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 >>>> <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. >>>> >>>
