Re: helper threads layer

[Javier Guerra <javier@...>]

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?

not yet...

'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 
macros)

> 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.

-- 
Javier

Attachment: pgpybYu9l3gl8.pgp
Description: PGP signature