patrickmacarthur / tpool Goto Github PK

Test the library with a very simple test case and make sure it works.

If future_destroy() is called when the value is not yet ready, it will return EBUSY without releasing the lock. This means that any subsequent calls to future_get() will block forever regardless of the status of the future value.

Forgot to destroy thread pool mutex in tpool_destroy()

I envision the following three scenarios:

1. default case: This is the way that it is right now. A new thread would be spawned for the task if there are more threads available; otherwise, the task would be queued.
2. queued mode (e.g., task->flags & TPOOL_TASK_QUEUED): The task would be always queued unless there are no threads currently running in the pool, in which case a thread would be spawned for the task.
3. immediate exclusive mode (e.g., task->flags & TPOOL_TASK_IMMEDIATE): A new thread would be spawned for the task if there are more threads available; otherwise, tpool_submit() would return EBUSY.

Flag names aren't set in stone yet. If the two constants that I used above are used, then TPOOL_TASK_QUEUED and TPOOL_TASK_IMMEDIATE will be mutually exclusive (if used together, tpool_submit would return EINVAL).

Right now, some API calls are non-blocking and others are blocking. The idea would be to make all API calls non-blocking by default (so that you could, for example, check on a task, and if the task is not completed yet, do something else). A TPOOL_WAIT flag would be added and supported by most API functions (where it makes sense) so that you could also make a blocking call if you wanted.

tpool_submit() takes 5 arguments currently, one of which is optional if the previous argument is not supplied. It may be clearer if we just export a struct to the user, and have the user fill in the struct and then pass the struct in as arguments. This would make this function similar to sigaction(2).

Thus, the new signature would be

int
tpool_submit(TPOOL *tpool, struct tpool_task *task, FUTURE **future)
{
}

and the struct would most likely contain:

struct tpool_task {
        void *(*task)(void *);
        void *arg;
        int flags;
};

This would also require that the queue create its own internal chain structure that also kept track of associated internal structures for each task.