Re: [AD] public thread API

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2008-08-05, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> On Wed, 2008-08-06 at 00:03 +1000, Peter Wang wrote:
> > Hi, 
> > 
> > A couple of weeks (months) ago there was a re-suggestion to expose a
> > thread API.  At that time I started writing down the docs for such a
> > thing then forgot about it.  Here it is, in source and rendered HTML.
> > 
> > I think I was the only one who had objections to including a thread API,
> > so whoever feels like working on this should go right ahead.
> > The internal API mostly matches this already.
> 
> Yeah. I can commit a file with the public wrapper functions and a
> test/example later today, unless it will take more than an hour or so to
> write it.
> 
> > * initialisation functions take preallocated objects; should they
> >   allocate on the heap and return pointers instead?
> 
> For consistency with the rest of the API, I'd say yes.
> 
> > * I didn't stray from the pthreads word order; should we?
> > 
> 
> word order?

As in, al_create_thread, al_lock_mutex, al_broadcast_cond.  Which looks
fine actually.  We should do it for consistency.

> One thing I'm wondering now, if we use the malloc/free way instead of
> preallocation, should we provide a separate
> al_thread_create/al_thread_destroy to do the allocation, and rename the
> current al_thead_create to al_thread_start?

Yes, I think this would be quite useful.

Taking it a bit further, al_create_thread could not just allocate the
space for the thread handle, but call pthread_create.  But we would not
actually execute the user's thread function until al_start_thread.
I believe this is useful for cases like:

    T = al_create_thread(thread_func);
    do further initialisation, using T
    al_start_thread(T);

Not sure how common it is.

Peter