| Re: [AD] public thread API |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
The 'deferred start' is useful if you're creating two or more threads
that communicate with each other, then you can set them both up before
they start running.
As far as I can see this API is a wrapper/renaming of pthreads. It's
good to provide this as I imagine there might be problems if someone
uses a different thread library alongside what Allegro is using
internally. I've never used threads in a game before but maybe we
could have a think about possible uses and provide an API which is
more helpful for game programming.
Pete
On 8/6/08, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> 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
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>