Re: Kernel KAPI and instrumentation mods

[Nick Garnett <nickg at ecoscentric dot com>]

Jonathan Larmour <jifl@eCosCentric.com> writes:

> Nick Garnett wrote:
> > Well, I also added an assignment in the thread destructor to zero the
> > thread id. So if the memory has been reused, even for another thread,
> > the id check will fail and it won't touch the list links.
> 
> True. It makes the probability 0.001% rather than 1%. Hmm.. is this
> good enough still though. Anyone else's opinion before I potentially
> flog a dead horse?

To be 100% safe the unique id stuff needs to be overhauled to ensure
that there were no duplicates. We would also need to add either a scan
of the thread list each time, or a table mapping unique ids into
threads. All of which is extra overhead.

I'm not sure that it really merits this much extra mechanism.

> >>Why pass in the id at all if it must match the thread handle?
> > For the same reason as above. The thread object memory may have been
> > reused in the interim. Double checking the id give us a simple
> > integrity check.
> 
> Ah, I was assuming the user would be forced to use a valid thread
> handle since they "have the threads", but if they used
> cyg_thread_get_next i.e. they don't know what thread it really is,
> then I guess not.
> 

The main use for these is really to permit a program to enumerate the
list of thread available and get some info about them in a reasonably
efficient manner. Just like the example shows.

-- 
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.com/