[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: helper threads layer
- From: Javier Guerra <javier@...>
- Date: Thu, 9 Mar 2006 18:12:59 -0500
On Thursday 09 March 2006 5:39 pm, Vijay Aswadhati wrote:
> Thank you for taking the time to explain with an example. I think it
> is reminiscent of the Windows QueueUserWorkItem() API. The missing
> part provided by your package is the use of queues to make it safe
> to communicate the results to the Lua universe. Do these queues
> provide a 'peek' and 'wait for a duration' functions?
'peek' would be easy, but 'wait for a duration' not so much.
BTW, i've only write it in Linux; i guess the structure would work in windows,
but it'll need some kind of API compatibility layer (hopefully just a few
> I am interested in durable tasks that run outside the Lua universe
> and emit application events that need to be transported into the Lua
> universe safely.
>From the example you have provided and what I have understood so far
> it seems like the package is meant for one-shot (i.e ephemeral)
> tasks which just run to completion. Is that a fair observation? Or
> am I not looking hard enough?
each task runs only once, but threads stay running until explicitly killed.
the idea is that you would spawn several threads, even on the same
input/output queues. another possibility is to have several input queues and
a single output queue, or anything like this. that makes it more desirable
to have 'peek' and 'wait for a duration' functions.
i think it would be possible to do some control inversion to get the
'application events' pattern.
> If all of the above seem shallow arguments then I use my parachute
> to remind you that I did preface it as 'on a frivolous note...'
i'm not proud of the 'helper' name; but i remember seeing this kind of tricks
referred as "helper threads".
i still have some linking quirks to clean up, and i'll post it. i hope to
have a better name by then.
Description: PGP signature