[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: helper threads layer
- From: "Vijay Aswadhati" <wyseman@...>
- Date: Thu, 9 Mar 2006 14:39:24 -0800
On Thursday, March 09, 2006 1:07 PM, Javier Guerra wrote:
> i hope so! either because it's accepted, or because somebody does
> something much better after seeing this as a proof of concept.
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?
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?
> i'm notoriously bad at picking names for my code... any
> explanation why you think 'concurrency' is better than 'helper'?
Glad to know that I am not alone. My suggestion to name it
'conurrency' package may be inappropriate as well if my
understanding of the package is correct. Still it looks promising so
here are my thoughts:
- Java has a 'concurrency' package that provides several different
ways to 'execute' something concurrently and how these executables
get scheduled. My first read felt like there were similarities in
scope.
- In a mult-cpu machine the task may indeed be executing
concurrently.
- It has the potential to be 'the concurrency' package ;-)
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...'
Cheers
Vijay Aswadhati