Re: [ANN] LuaTask 1.6.1

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

On 7/3/07, Duck <duck@roaming.ath.cx> wrote:
> [snipped info about fiddling with TASK_SLOTS_STEP]
[snipped info about yer program]
> And to prevent the realloc(), I've just changed this in ltask.c, so that
> the TASK_SLOT_STEPping never happens and the problem is apparently
> prevented:
>
> [in int_taskcreate]
>    for( i = 0; i < countTask; i++)
>      if( !( aTask[i].running))
>        break;
>    if( i == countTask) {
>      TASK_ENTRY *te;
>      long j;
>
>      te = ( TASK_ENTRY *) realloc( aTask, sizeof( TASK_ENTRY) * ( countTask + TASK_SLOTS_STEP));
>      if( te == NULL) {
>        OsUnlockMutex( tlMutex);
>        return( -1);
>      }
>      aTask = te;

A race with the aTask pointer update might be your problem :-/

If I understand the design of LuaTasks right, there may be several
threads calling into functions in ltask.c at once, and they are only
synchronized with the tlMutex global. You do well to serialize updates
to the aTask pointer, however there are several functions which do not
lock on access (reg_tasklist, reg_taskreceive, reg_getqhandle), which
lead to a race. Let me illustrate:

Let's say the realloc executes, and returns a new pointer ('te' in the
above code snipplet). realloc() needn't return a new pointer, but
often it will do just that. The old pointer - the global aTask, is
free() and invalid right after the realloc() call, yet any other
thread that has the old pointer might end up dereferencing aTask
before you manage to assign it the new pointer.

That should explain your random crashes, and why they don't always happen.

Solution? Lock all accesses - reads and writes - through any globals
in a multithreaded environment.

-Kacper