[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Comments on "BBN's Proposed extensions for data n

From: David Lapsley
Subject: Re: [Discuss-gnuradio] Comments on "BBN's Proposed extensions for data networking"
Date: Thu, 08 Jun 2006 05:55:26 -0400
User-agent: Thunderbird (Macintosh/20060530)

Eric Blossom wrote:
On Thu, Jun 08, 2006 at 12:38:02AM -0400, David Lapsley wrote:
--> These seem in conflict with each other. Further, the only obvious reference in 4.8.2 to the relinquishing of control is the "yield()" function. Maybe: The "gr single threaded scheduler" is run in a separate thread from the executing m-block, and the m-block sleeps for a set time (the "scheduling quantum") ... it will wake up if the thread finishes or if the sleep returns, at which point it checks the state of the thread, and either yields to the m-scheduler, or returns the gr-scheduler's data.
Yes. The "gr single threaded scheduler" runs in its own thread. The sequence you suggest should work just fine.

Nope.  gr_single_threaded_scheduler (or something above it) will be
called from the handle_message callback of the mblock, and thus will
execute on the mblock's thread.


FWIW, I think all this stuff about scheduler quanta is confusing, and
should be deleted.  I'm assuming that everything is "run to completion".
If you want a shorter interval until completion, bite off smaller
chunks.  I don't think any of this really needs to be in the doc, but
will fall out as an implementation detail.

Agreed.  I'll make the necessary changes.



Attachment: dlapsley.vcf
Description: Vcard

reply via email to

[Prev in Thread] Current Thread [Next in Thread]