Re: French translation updated & Yet Another Scripting Idea.

On Tue, Nov 08, 2005 at 05:14:21PM +0100, Nicolas Noble wrote:
> The way I roughly see it is the following:
> 1) consider that running a simple "runnable Lua class" wouldn't block
> (atomic calls, if we forget about endless loops yet - even though this
> might get solved by itself afterward, since it's somewhat possible to
> force it to yield every XX instructions for example, but yet I am not
> 100% sure if this is safe, so maybe it's better to keep it for later).
> So that this runnable Lua class wouldn't directly set up any wake-up
> condition.
> 2) the Lua VM itself might call back some of the Lftp's functions, which
> in turn would probably want to yield and set up wake-up conditions.
> These conditions should be fowarded to the Lua class so that it gets
> woken up correctly and try to execute the Do method of the class which
> caused the yield. If the class still wants to sleep, repeat. Otherwise,
> resume the Lua VM with the correct return. Since code is usually better
> than english words, if you want a better idea about how the Lua
> threading system works, you can read a complete example here:
> http://paste.nobis-crew.org/51 and its results when run at:
> http://paste.nobis-crew.org/52

Ok, it is a good plan. LUA really seems to fit well in lftp.

> Actually, given your next paragraph, there's something I still didn't
> understand correctly: does a SMTask object has to set a wake-up
> condition for "I want to be woken-up as soon as this object is in state
> MOVED" ? Or would each SMTask object be woken-up as soon as any object
> goes in MOVED state ?

Currently scheduler is not very efficient, and it lets all tasks run when
any wake up condition happens, or when any task returns MOVED. It simplifies
inter-task relations - no need to keep track of them.

>               if (!subjob->Done())
>                   return m;
>               state = RUN_CODE;
>               delete subjob;  // didn't notice that in your code yet ;
> are the SMTask garbage-collected in the Scheduler ?

tasks should be Delete'd (note the capital letter) when they are not needed.
direct delete call is not allowed (except in some special cases), because
the task can be running at the time.

> int wrapper_for_some_binding(lua_State * L) {
>   LuaJob * lj = findparent(L);
>   lj->subjob = new the_luaSMTask_for_that_binding(L);
>   return lua_yield(L, 0);
> }
>
> The "drawback" of this is that we have to create a lots of SMTask class,
> one for each binding. But it makes sense anyway: the binding has to be a
> task anyway since it'll most probably fire up some more atomic
> subcommands in order to process the Lua's request.

create/delete a task is fast, but it is not desirable to have too many tasks
at once (because scheduler is inefficient).

I think it is possible to do some simple work inside LuaJob task, creating
additional states. Some more complex tasks should be made separate.

> Well, I am in the right direction or completely wrong understanding how
> it should be handled ? :)

Seems to be right direction.

--
   Alexander.