Thanks Spencer, it worked. Only took two lines of code.
On Tuesday, April 21, 2015 at 12:53:49 PM UTC-6, Spencer Russell wrote: > > 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 <jay.ki...@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. > > >
