Re: Lua and light threads

["Stefano Lanzavecchia" <stf@...>]

Bret wrote:

> I guess I've misled you all if I said I completely eliminated the
> recursion... I eliminated it for the common ("direct") case,
> where it was
> necessary in order to support an explicit sleep.  Where that's not
> necessary, I still let it happen.

I had kind of guessed that :-)

> With Roberto, Luiz, and Waldemar's permission, I would very
> much like to
> contribute this first part to the next 4.0 beta. This is no
> way changes Lua
> semantics and should have a negligible effect on speed. All
> it does is make
> the remaining cooperative-task work splice more naturally
> into the base
> code so that the eventual patch is more intelligible.  I'm
> hoping to finish
> this part this weekend.

I would very much love to see this (to compare it with the horrible version
I coded this weekend) even if it won't get into any official release.

>
> Sorry to be so long-winded...

Not at all. The more you say the more I understand :)

Now, about OP_TAILCALL. As I mentioned earlier I managed to avoid recursive
calls to luaD_call in the cases Bret calls "direct" invocations, but in the
process I discovered a nasty surprise: OP_TAILCALL as implemented in the
original luaV_execute is not a tail-call at all (as normally intended in
functional programming languages), since it grows the C-stack. I thought I
could make it a real tail call but I did not manage to even in my version
which does not use the C stack. I could have made a big mistake, but it
would appear that the Lua compiler (!?!?) actually expects OP_TAILCALL to
create an extra frame in the calling stack, therefore invalidating all my
attempts at reusing the current one, as customary when dealing with tail
calls. Can anybody comment on this?


Now Sebby:

> 		_asm
> 		{
> 			mov esp, Stack;
> 		}
>

Thanks a lot for your sample. It's really inspiring. Alas, this little trick
it's the reason why I cannot use the strategy then: the code must be
platform independent and I am not sure how to change this for the port to
Risc machines. Anyway, I'll keep in mind that this is a possibility.

For Luiz:

> >A heart-felt "thank you" to the developers at Teccgraf who
> are so nice and
> >let us have the fruit of their work for free.
>
> It's nice to know Lua is being used for many applications.
> What we ask from you users is credit and an entry in our
> projects page, so
> that we can show that Lua is indeed being widely used; this
> will help a lot
> towards ensuring further support for developing Lua at TeCGraf.

Rest assured that, if the project goes anywhere, you'll hear again
officially from me with a request for inclusion in the project list. At the
moment it would be a bit premature...



And Kelvin:


> I didn't phrase myself properly.  I meant that stackless
> Python was simular
> to what several people want to achieve with Lua.  I wasn't
> suggesting that
> people switch to Python.  I was suggesting it could be used
> as a point of
> reference and inspiration.

Actually, I understood what you meant. And it was exactly my approach. At
the moment the problems I see with it are as following:
1) Python (these are words by the author of the stackless version) was
already almost Stackless. Execution frames were already being built, only
they weren't used as a proper stack. Lua makes this transition much harder,
a bit less in the case only "direct" calls to luaD_call are considered.
2) The Python module to deal with continuation built by the same author is
very complex and very tricky (again, his words) and was developed over
several years. The project I am involved with considers months "a very long
period". I don't think I can stall the development of the game simply to
redo all that work (assuming I am good enough to do it). As a long term
strategy, it seems a valuable alternative though.
3) The various functions which call luaD_call have different return types,
whereas it seems that in Lua almost all of them already returned a PyObject.
This means that the original logic of the source code must be revised much
more in Lua than in Python to flatten the recursive calls and turn them into
the building of continuations encapsulating frames. It is certainly
possible, but it's not going to be trivial, especially if the guys from
Teccgraf are not interested in this, since it would mean a complete rewrite
of ldo.c, lvm.c and possibly other bits and pieces (what about the garbage
collector?). Maybe this would not be considered top priority for a language
which is now several years old and has already proven to be more than simply
useful as it stands.

This said, I would really love if somebody could prove me wrong, and build
efficient continuations in Lua in a couple of weeks :)

--
WildHeart'2k - mailto:stf@apl.it
Homepage: http://come.to/wildheart/
<<<Non c'e' cuore che non speri al di la' di qualunque possibile
speranza ---
   WildHeart'98 productions>>>