[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua and preemptive scheduling for coroutines
- From: Jose Luis Hidalgo <joseluis.hidalgo@...>
- Date: Wed, 3 Apr 2013 10:54:27 +0200
>
> It would be nice if you'd add it. I guess it is a matter of registering a debug hook (e.g. count hook) and then yielding inside it? Or is it actually forbidden to yield inside the hook? If so, you'll need to use some tricks similar to what I've done.
>
> You could do a hook registration in a lazy way, i.e. register only if user explicitly asks for preemptive multi-tasking for a given thread by e.g. using a new "async_preemptive" construct or a special additional argument to async(). This way, if nobody asks for it, there is no performance overhead.
Ok, I will try and see what happens.
> Another thing I'd like to understand better is how to marry your approach with something like an OS/native thread-pool ( I briefly asked about it in one of my messages. I wanted to see how thread-pools can be used in Lua). If this would be possible, one could schedule some of the active async threads to run really concurrently. One could also assign those coroutines which are semantically concurrent to different threads/thread pools and so on.
As far as I know, there is no problem in having different threads
managing a set of lua_States as long as they don't share a state at
any given time. There is no need to associate a lua_State to a given
thread.
> Just to check if I understand correctly. The wait_for construct could take some arguments, which would describe which events I'm waiting for. It will be stored somewhere in the Thread data. Later, when an event arrives, I can check by using this stored information and event information if this event matches what the waiting thread is expecting to see. If so, I can push some data (e.g. the content of this event) to the waiting thread and then signal this thread that it may continue its execution on next update. correct?
>
It is possible to access those values, in fact, you're called with the
lua stack as if the call was for your registered wait function:
virtual WaitForResult waitFor_implementation(Thread t_stack, int id) = 0;
In order to inherit from CoroutineManager you MUST implement that
function. You receive the id of the pushed waitFor function, and the
thread-stack with all the incoming arguments.
You can use anything you want to store the given data, what I do is
store the Thread stack in a list on the C side and once the signal is
triggered I notify the coroutineManager to start the execution of the
coroutine again. I don't use lua for that, but you can also use the
given lua_State to store information about the wait call, or whatever
you need.
> BTW, how would a waiting thread access this information returned from wait_for(signal1, signal2, ..., signalN)? Can I use something like this:
> async ( function () receivedEvent=wait_for(signal1, signal2, ..., signalN) end, .... )
signal1, signal2, signalN will be arguments passed on the Thread stack
to the waitFor_implementation function of the coroutineManager. To
return any value, you can use the pushResultToCoroutineStack of
coroutineManager to add values as result of the wait call.
Regards,
JLH
--
JLH