Reentrant is more than just that. It also means that if a thread is
killed, at any point short of completion of the thread, I can restart
the thread from the original starting parameters and it will perform
properly.
For instance, if I have a program that (in essence) writes a file that
contains all of the filenames on the machine to a file, and then run
this file, I would expect that if I start it, kill it halfway, and
restart it, that I would only get, for example, one /etc, not
something like
/etc/
/etc/hosts
/etc/passwd
<killed>
/etc/
/etc/hosts
/etc/passwd
/etc/config
etc.
in my file.... that would be non-reentrant (although this is not a thread
program, it shows re-entrant concerns at a grosser level).
I would get a SINGLE element on all the parts.
Another example (and one I did extensively) was to convert files from
one format to another, and store the output to a RDBS. Let's say that
I get to the point I have converted the file and now need to put the
information into the RDBS. The RDBS has two seperate databases that I need
to insert into... I need to ensure that I do not create duplicate entries
if one insert goes before a second, and COMMIT does not work with multiple
databases.... so I need to create a re-entrant module that can determine
if I have committed the changes to one database but not the other before
reapplying them.
In the trivial case, reentrant code that is reentered
after it has executed to completion should do NOTHING except set whatever
flags need to be set to show that it has completed successfully.
Again, this is grossly oversimplified.
Bill Ward
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 29, 2000 2:46 PM
To: [EMAIL PROTECTED]
Subject: Re: Threads !!
David D.W. Downey wrote:
> Aboslutely fragging GREAT! I think I've become able to understand
more
> about certain things in the last 5 minutes than I have in quite awhile.
Warm fuzzies.
> The only thing I don't understand is the term re-entrant.
>
> re-entrant == re enter a function o something? as in NOT doing this or
> MUST be able to do this? and why is that a bad thing(tm)?
This is an old concept. Essentially, if you don't take some pains to
guarantee that the function can support such usage, it's possible to
cause severe heartburn if you call a function from itself, or from some
other function that was called by it (and/or deeper in such a chain.)
A good example of things that break reentrancy is declaration of static
variables within a function, without making provision for being called
while they're in use. E.g., a static array and static depth index, bumped
whenever the function is called and decremented on exit, would help
fix reentrancy for data that might have to be shared with later
instantiations
of yourself. If you don't need to share the data, stack-resident data
nicely
avoids the issue. Another item is partially modifying global data (boo,
hiss--but another topic), then calling something that re-enters yourself.
You now have left that data in an "inconsistent" state.
It's not exceedingly difficult; but it's easy to forget to consider data
usage with it in mind.
Cheers,
--
Dave Ihnat
[EMAIL PROTECTED]
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
