[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Creating a New Thread?
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Creating a New Thread? |
Date: |
Fri, 6 Jan 2006 16:24:32 -0800 |
User-agent: |
Mutt/1.5.6i |
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