On Thu, 30 March 2000, Ward William E PHDN wrote:
>
> 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.
Actually, no. Reentrancy does NOT allow for such behavior. If a thread
is killed, its resources are presumed reclaimed. Therefore, no "state information"
about where it was in its course of processing would be preserved. This is the
normal and expected behavior of a terminated (or killed) thread.
What you're talking about is thread resumption. If you pause/suspend an
executing thread, you can later resume it, picking up "where it left off."
When working in a threaded environment, one of the primary concerns is
resource contention. When working in an environment where you're going to
arbitrarily (i.e. unexpected or uncoordinated, as far as the thread is concerned)
suspend/resume threads, you're now worried about stale resources. That's a whole
other can of worms.
>
> 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.
Actually, getting the "duplciates" is exactly what you WOULD expect.
>
> 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]
>
>
[snip]
_______________________________________________________
Are you a Techie? Get Your Free Tech Email Address Now!
Many to choose from! Visit http://www.TechEmail.com
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
