Dev Ramudit wrote: > Thanks for your help John, I haven't tried it yet, but the > gr.udp_source/sink seems like it would work pretty well for what I > need to do. Reading through your comments and spending more time with > my previous code, it seems like you're correct about the C++ portions > of gnuradio not being able to call back up to my python general_work > function. I've been reading through various portions of the codebase > and the SWIG docs, and I've thought of a couple of things that might > work (using SWIG directors maybe?). I'll try to come back at some > point and submit that patch :)
It gets more complicated, though, as the flowgraph is operating in a different thread from the Python interpreter "main" thread that calls fg.run(). So calling back up into Python via SWIG will need management of the Python global interpreter lock, and you need to worry about all the typical multi-threaded issues of deadlock and race conditions. If I haven't scared you into using gr.udp_source/sink yet, then study the gr_feval.* implementation in the trunk code. You won't be able to use this directly but it does show all the hackery needed to go back up into Python from C++ when running in a separate thread. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
