Re: LibEvent binding to Lua? Mix w/ HelperThreads?

[Javier Guerra <javier@...>]

On Tuesday 04 April 2006 4:47 pm, Doug Currie wrote:
> But does it need to be the *same* C API on all platforms? I don't see
> why since, assuming I/O is involved, there will be separate
> implementations for each platform anyway.

several core libraries are very similar on both systems, otherwise LuaSocket 
and LuaThreads would be much more complex. (they use some thin function 
adaptors to make it multiplatform).

also, there are many interesting libraries that are totally multiplatform 
(most SQL DBs, XML processes).

and any project that wants to embed Lua and expose it's internal functions as 
an asynchronous API would have to do it different for each platform

> If the C API is the same on all platforms, it will need to be very
> abstract, and very minimal.

or maybe expose different APIs for different environments, enabled/disabled 
with compile-time switches.

for example: HTT requires pthreads, but on some embedded systems it's more 
appropriate to use a polling API.  maybe a library that uses HTT could be 
registered to be polled, and on a threading-capable system a thread would do 
the polling.

also, most arguments against HTT seem to be that events are 'better' than 
threads... that's true, but not so much as it used to be.  modern systems 
(Linux and Solaris, at least) can easily handle tens of thousands of threads 
without degrading performance

> Here's an example: HelperThreads has a queue-peek API. This is not
> possible with IOCP on Windows (at least, I don't know how to do it
> without polling and re-enqueuing which would break the FIFO
> semantics).

if that's a big problem, don't worry. i included peek() just because it seemed 
right.  i haven't used it (yet?)

> Another example: IOCP AIO system I/O functions initiate I/O and
> enqueue in the same system call. In HelperThreads this is two
> operations.

this could be adapted by some ingenious use of wrappers... but might instead 
be a motivation to alter the Lua API.

HTT is a proof that it could be done, and that it would make it easier to 
write AIO C libraries.  by no means a 'definite' system.

> On the other hand, there is no impediment to using threads with IOCP.
> There is a enqueue-completion-status C API for IOCP, so a user thread
> can interact with the same queue used by system i/o completion. So it
> would be possible to build a Win32 library that used AIO system calls
> where available, and user threads where not, while maintaining the
> illusion of all AIO (just as HelperThreads does but with a stripped
> down API).

yep, once you have a preemptive threading system, it's very easy to use any 
kind of subyacent API

-- 
Javier

Attachment: pgpnZd5cTE02S.pgp
Description: PGP signature