On Fri, Jan 06, 2006 at 08:22:07AM -0500, Michael Dickens wrote: > Does GR have a preferred way to create a new thread? I don't know if > it will work for what I need, but it's worth a try. If it doesn't > work, then I have an email queued to Apple's USB list asking my next > question:
If you talking about creating a thread in C++, we use the omnithread package. It's a thin C++ wrapper on top of posix threads. Docs in gnuradio-core/doc/other/omnithread.pdf If in Python, we use the standard threading package. > The problem is in doing the USB callback under OSX at the - > application- level, there seems to be no way to do it without > blocking (via the run loop). There are other ways at lower levels, > but those are -kernel- things, which really should be kept to kext's > and such (and don't compile without easily in an application for > whatever reason). So my thought is that, since the run loop is be > applied to the whole application and all it's threads, to create a > new thread to run the loop, thus freeing up both the "read", "write", > and OSX callbacks from having to deal with this blocking. > > It's worth noting that the LIBUSB folks are working on getting async > and isoch data transport implemented in a more robust fashion ... but > who knows when that will be released? - MLD Isoch is of no interest to us (can't obtain the throughput you can get with bulk), but getting the async stuff implemented in a standard way would be good. They do know about our fusb_* code. Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
