This is the mail archive of the
mailing list for the eCos project.
Re: "Threads on ecos" confirmation needed...
- From: Ivan Horvat <ihorvat at xylon dot hr>
- To: Dirk Broer <dbroer at matrics dot com>, ecos-discuss<ecos-discuss at sources dot redhat dot com>
- Date: Fri, 30 Jan 2004 20:22:47 +0100
- Subject: Re: [ECOS] "Threads on ecos" confirmation needed...
- References: <EFEEIJLMMJEMDAEMCNIGGEMMCNAA.email@example.com>
Dirk Broer wrote:
As best I can tell.
We use POSIX interface to threads. We join on the threads all the time. At
some points of execution, I can say we are creating and destroying 5 threads
a second, potentially over an extended period of time with no ill effects.
All threads are joined, but we don't do much in the way of cleanup so its
not a tough test. Threads are encapsulated in a C++ object, using static
methods for callbacks.
1) Consider ECOS threads directly if you can. POSIX threads aren't named
and makes debugging easier.
2) We need to clean up our thread per task algorithm. (yeah, sure, when we
Nice lessons, especially 1) :-)
I actually want to avoid joining threads. I'm using omnithread wrapper
actually broken for DETACHED type of threads: it deletes the object
the storage for Cyg_Thread object (returned by cyg_thread_create())
cyg_thread_exit(), which soon crashes the scheduler.
There is no ill effects using UNDETACHED treads only if there is a
to join them as much as possible, but this is not very elegant. The
pthreads are more
common so I would like to use that API instead, but it obviously have
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss