[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Random crashed with threaded application
- From: William Ahern <william@...>
- Date: Thu, 20 Jun 2013 15:57:57 -0700
On Thu, Jun 20, 2013 at 02:48:36PM -0700, Coda Highland wrote:
> That's rather outside the scope of Lua as an embeddable scripting
> language, not to mention it would have some terrible overhead for the
> most common use case of a single thread. It also can't be done in ANSI
> C -- note that Python has the same restrictions to multithreading, but
> it has platform-specific threading primitives in place as the Global
> Interpreter Lock to avoid conflicts.
>
> If you really want to see Lua with multithreading, take a look at Lanes.
It's not as cool as Lua Lanes, but my cqueues project implements a simple
POSIX thread primitive which works with the builtin sockets library.
So, the routine
thread.start(function [, string [, string ... ]])
returns two values--a thread object and a socket object. The new thread
instantiates a Lua VM, as well as preloading some libraries by copying them
from the original VM, in case the process is in a chroot'd environment where
the original modules are no longer visible.
The function is invoked in the new thread and receives a socket object
followed by all the string parameters passed to thread.start.
The only method on a thread object is :join(). No attempt is made to
optimize data sharing. Rather, Unix domain socket forwarding is made simple
via the socket module's :sendfd and :recvfd methods.
The whole concept is to just make the existing Unix primitives easy to use.
Which is to say, not merely providing C bindings to syscalls, but to really
try to mesh Unix IPC and Lua into a convenient package, especially for
writing server software.
My ultimate goal is something on par with Erlang, Twisted Python, etc.
Except the Lua way, which is don't dictate to the application that it must
follow your model, just make your design model readily accessible and
convenient to integrate.