lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 15 February 2012 21:52, Ezra Sims <> wrote:
> 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?

The solution to wake the event loop would be to create a file
descriptor Verse can watch on (a file, pipe, local socket, etc.)
alongside the "real" connection(s). Then any thread can send something
on the watched fd to wake up select() and trigger whatever action is