Re: Tuna now in module form
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Tuna now in module form
- From: Ezra Sims <ezra.sims@...>
- Date: 2012年2月15日 16:52:11 -0500
On 2/15/2012 2:42 PM, curt wrote:
On 2/15/2012 3:02 AM, Ezra Sims wrote:
Cool, I'll give it a shot later tomorrow. I hadn't thought to mess
with the optimization flags.
As a point of curiosity in the meantime, could you explain how Tuna
interacts with the Lua state during blocking functions? Using a
crappy homebrew thread API I was able to fire functions across
threaded states (using a really basic lock-everything approach)
without too many problems, pretty much no matter what either state
was doing. The thread could be in the middle of a sleep loop or
Verse's event loop and I wouldn't have to worry waiting for it to
complete or yield unless a block was desired. Can I expect about the
same behavior from Tuna, or would I need some extra action within
those loops?
If I understand your question correctly, using two different states
(two separate threads, for Tuna) then they are not allowed to interact
in any way other than sending messages to each other, the same as
Lanes. They will process simultaneously and never lock each other, you
don't need to do anything special.
If you mean to different Tasks withing the same state (Which Tuna
does) then only one can process at a time, they share the same global
space and are scheduled cooperatively. If you have a loop in one, it
will execute until it yields (tuna.yield() for example) or does
something else that asks Tuna to do something for it, like sleep or
send/receive a blocking message.
Locking is not required since the underlying c-stacks are held
separately, they preserve all state information when yielded, and
mutexes are not requires since when a task is operating it cannot be
interrupted unless (as I just mentioned) it explicitly yields.
Does that help? I'm not sure I am answering what you are asking.
-Curt
Somewhat, yes. Separate threads are needed for the project, there would
be very little done with Tasks. I have yet to mess around with a Tuna
implementation, so I'm sure I'll figure it out as I go, but here's the
case I'd be running into:
The project is a extensible XMPP-based virtual assistant of sorts.
Thread 1, the host, runs through initialization and spawns a thread for
Verse (the XMPP client lib), then dispatches a thread for each
extension. From there on the host acts as a proxy between the extensions
and Verse. The goal here is to provide as much flexibility for the
extensions as possible, letting them do whatever they need to do without
providing direct control over the XMPP connection or allowing access to
potentially sensitive information.
Verse runs an event loop that relies on hooks to fire functions within
the environment, not breaking from the loop until disconnect. For a chat
client or bot this is perfect, but in this case it's expected that an
extension will be able to send or receive messages at any time (be it by
reflex, timer, or whim), which would require the ability to interrupt
that loop.
I suppose the real question here is, how can I pull that off in a sane
way? Breaking from extension sleeps is a whole other matter which I can
work around using a dedicated timer thread or somesuch, but Verse itself
is worrisome. If I can't directly interrupt the loop with a message, am
I able to just yield the thread, pass a message, act on it, and then
resume? If yes, awesome. If no, would you have a better idea or at least
a point in the right direction?