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: cyg_thread_kill and info threads



andrew.lunn@ascom.ch (Andrew Lunn) writes:
> > It depends on what the thread was doing (or if not running or ready, how it
> > was not running or ready).
> 
> Commiting suicide im my case:
>         cyg_thread_kill(cyg_thread_self());
> 
> > The exception is the GDB thread info queue, where killed threads remain
> > recorded, since (in uITRON for example) you can trivially re-run the thread
> > and are expected to so do.
> 
> So does this imply that eCos still uses the cyg_thread * thread
> paremeter passed to cyg_thread_create, even when the thread has been
> killed?

Yes.  Killing the thread is quite separate from destroying it.  Strictly
speaking, the thread-aware debugging code, which for most platforms is only
active when built-in GDB stubs are used, is what is using the thread object
after it has exited.

Non-debugging configurations of eCos certainly would not keep references to
otherwise "dead" objects.

This is the correct thing to do; suppose your thread were exiting
prematurely due to a bug.  You would want "info threads" to show you it, so
you can select it and do a backtrace maybe, to see where your code called
exit(), and so on, to work out how it died.

> I reuse these so this may be my problem.

Yup.  It's a straightforward circular linked list inside, so if you have an
array of thread objects that you only ever use for threads, at the same set
of addresses, it should be OK.  But if you blast the thread object itself
to zero, or arbitrarily re-use the memory, that would break the pointers,
and a subsequent new-thread operation would go wrong as it scans the list
as part of adding that new thread - it is tolerant to re-initializing an
active thread object, ie. adding it to the list a 2nd time.
  
> > To remove it from the GDB thread info queue, first ensure it has actually
> > exited, then call the destructor ~Cyg_Thread().
> > 
> > The KAPI has a suitable utility:
> > 
> >    externC cyg_bool_t cyg_thread_delete( cyg_handle_t thread )
> 
> The 1.2.10 documentation does not list this one, but it does exist in
> the code. Is it in the 1.3.1 documentation?

Not as far as I can see. ;-(

	- Huge

-- 
The 20th Century brought unprecedented increases in worldwide numeracy and
literacy and incredible advances in technology, science and mathematics.
It was also the only century in the past or in any reasonable predictable
future apparently to contain only 99 years.


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