This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Waitin Thread to finish
- To: 'Jonathan Larmour' <jlarmour at redhat dot co dot uk>
- Subject: RE: [ECOS] Waitin Thread to finish
- From: Fabrice Gautier <Fabrice_Gautier at sdesigns dot com>
- Date: Thu, 3 Aug 2000 16:24:11 -0700
- Cc: "Ecos-List (E-mail)" <ecos-discuss at sourceware dot cygnus dot com>
> -----Original Message-----
> From: Jonathan Larmour [mailto:jlarmour@redhat.co.uk]
> Subject: Re: [ECOS] Waitin Thread to finish
> By signalling a condition variable when your thread exits!
Yeap.. But the problem in that the code i will wait is already written and
not with eCos in mind...
> If you are looking for that type of over-featuredness like, say, from
> pthread_join(), then you could wait for the EL/IX work to be merged in
> soon[1].
Yes soon...
Anyway, in the thread structure, the handle is called unique_id. In what
extent is this id unique? Is it unique among existing task? Or unique among
all task that have ever been ? How is this handle allocated by eCos?
And how does the C API does the type conversion from cyg_handle_t to
Cyg_Thread class? What does occur if the C++ object is deleted when I call a
C API function that refer to the handle of the deleted object?
(Can "if(self==NULL)" do soemthing good?)
Thank You
A+
--
Fabrice Gautier
fabrice_gautier@sdesigns.com