lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

"Kacper Wysocki" <> wrote:
> 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 am not sure that this line is indeed a problem. Isn't checking an int
an atomic operation? As aTask is declared volatile, it should be
re-referenced, so a change during the loop would not be a problem

Further down in that function there are a couple of string copy ops, but
even these should be safe, I think.

cheers  thomasl

web :