This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Waitin Thread to finish


Fabrice Gautier wrote:
> 
> > -----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...

Sure, but even that code can be wrapped - instead of called
cyg_thread_create(), call fabrice_thread_create() :-). That creates an eCos
thread with your own entry point. That entry point calls the thread entry
point supplied to fabrice_thread_create, *but* when the thread returns, it
signals the condition variable.

Similarly, make a fabrice_exit() :-) which threads call if they want to
exit directly, rather than exit by dropping off the bottom of their entry
function.

> > 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...

I know, it's getting repetitive :-).
 
> 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?

Unique among all tasks, unless you create more than 65536 threads anyway.
It's simply allocated by incrementing a counter and giving a new thread the
new counter value.
 
> 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?)

Use the source Luke! If the c++ object is deleted, it will all go very
wrong, as you would expect for an efficient lightweight embedded system -
no excessive validation here! You'd be able to diagnose it if you build
eCos with asserts on though.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]