Re: RES: package system modification (module loaders)

[David Burgess <dburgess@...>]

caveat - Its late. it been a tough week and I am not in my best mood.

At the risk of inflaming this discussion, may I suggest that you read
Diego's words more carefully (he does not waste them).


> > Not true. You should use non-blocking I/O and avoid blocking altogether.

> How? You can't just do a wait loop. What you really want
> is blocking, but only blocking the current 'thread'.
> In particular, you may want to 'yield' from a coroutine
> which is resumed only when the request would be satisfied.

The techniques for non-blocking I/O in Unix are well studied.(IO completion 
ports  are a rough Win32 equivalent). Using threads and blocking (just because 
you can) is never a good option.
Single threaded NBIO always outperforms blocking IO and the code (whats more)
is usually simpler. 

<snip>
> On the contrary, that is precisely where you DO cancel
> Posix threads -- they're called cancallation points,
</snip>
Yes it can be done. It is a great way to build non-portable unstable
applications.

re: remainder
Lua, Luasocket and most of the Kepler project are typically small,
fast, reliable
and bug free (as things can be). Methinks this is due to a design and
implementation
that seeks simplicity and functionality over complexity. Multiplexed
event dispatching,
(given modern processors) leaves threaded design patterns a long way behind.

>So you'd do something like:
>
>do forever
>       e = read_gui_event()
>       w = widget_number_of_event (e)
>       thread = widgets[w]
>       resume (thread,e)
>end

May I suggest that you scan the list for Mike Pall's  proposal for Lua
event dispatch,
no threads.

DB

P.S.
I we wish to read about Felix we can visit the website.