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:
pgpDjYhPdWjSu.pgp
Description: PGP signature