Re: LuaTask needs your help

["Kacper Wysocki" <kacperw@...>]

On 7/7/07, Daniel Quintela <dq@soongsoft.com> wrote:
> I'm almost ready to release LuaTask 1.6.2
>
> I changed the way TASK_ENTRY memory is allocated.
>
> I would appreciate it very much if you could test it and give me some
> feedback.
>
> You can get the candidate from: http://www.soongsoft.com/lua/ltask.c

Hey Daniel,

good call on just resizing the array of task entries, instead of the
task entry structs themselves. That way the realloc won't affect the
running threads, and you save yourself a couple mutex locks. However,
you're still dereferencing the aTask pointer in tasklist(), getqhandle
and taskreceive() without grabbing the lock first, which will lead to
race conditions that are tough to pin down.

An example:
static int reg_tasklist(lua_State *L) {
   long i;
   lua_newtable( L);

   for( i = 0; i < countTask; i++)
       if( aTask[i]->running) { // <--- aTask pointer may have been
realloc()'ed elsewhere
           lua_pushnumber( L, i + 1);
           lua_newtable( L);

I suggest you lock down these aTask accesses... in reg_tasklist() you
will simply have to grab the mutex as you're iterating over the whole
task array,
but in taskreceive() and elsewhere,  if you want to avoid grabbing the
lock, you could push the task entry pointer (= aTask[i]) as a light
userdata upvalue for the lua apis OR as threaddata upon thread
creation.

I apologize for my laze in not producing a patch..
Cheers,
/K