Re: [Pan-users] Re: Re: Problem with filtering

[Calin A. Culianu]

On Mon, 6 Oct 2003, Duncan wrote:

> Calin A. Culianu posted
> <address@hidden>,
> excerpted below,  on Mon, 06 Oct 2003 10:20:03 -0400:
>
> > Check your defnitions.  Reentrancy has nothing to do with multitasking,
> > but rather multithreading.  You are describing a situation as being
> > related to reentrancy, but the situation you describe is not a situation
> > in which reentrancy of library routines is relevant.  This is because we
> > are talking about multiple processes using the same library, not
> > multiple threads of the same process (a bit difference).
>
> I'll disagree here.  I should mention I've done very little programming of
> any sort (beyond scripting, which obviously isn't the same league) on
> Linux, so if your background is there, you might be right within that
> context.  However, within the Windows context, reentrancy *DOES* also
> apply at the task/application level.  I know this having absorbed a

This is surprising indeed.  Can you point me to any such calls?

> significant number of API and Resource Kit explanations of the differences
> between the 9x "pseudo" 32-bit system and the NT family fully protected
> mode system, where the subject of reentrancy was VERY DEFINITELY discussed
> in terms of multi-tasking, because that was the very context of the

Can you point me to any literature or references?  I would be very curious
to see the term reentrancy used in such an incorrect manner.

> discussion in which it was brought up, that being how the NT architecture
> was at the same time more robust and more memory intensive than W9x, due
> to the very thing you mention below, the redesign of the system and all
> shared libraries to be "each app gets its own copy" rather than the more
> memory conservative but less robust due to bugs, "unique copy on write,
> shared copy while read-only until write" of much of the W9x system.

NT still does copy on write.  As does Linux or any modern OS.  There is no
point to keeping two copies of read-only memory.  To do otherwise would
mean to gain nothing and to waste a lot of memory that could have been
conserved.

I haven't done as much win32 programming as I have done Linux, and have
done zero win16 (windows 3.x or below) programming, so I don't know about
what issues there would be with legacy 16-bit, non-protected-mode apps and
libraries...

But it appears to me that there is some confusion here in this discussion
-- I detected an implication that there are some inherent issues with
sharing read-only code pages among multiple programs or threads.  It must
be made clear that there inherently are no issues with sharing read-only
memory pages, whether they be code (text/executable), or read-only data.

Two people sharing a book, or a car, or a piece of cake at the same time
have issues.  Two programs running in different address spaces sharing the
same physical pages for code have no issues.  That's one of the magical
things about computers.

Think of when you fire up two instances of mozilla.exe.  What windows does
is it keeps one physical in-memory copy of mozilla.exe's code.  The two
processes that are executing mozilla.exe's code are sharing it's code
pages, using copy-on-write to guarantee correctness in the case of
self-modifying code and modifications to the static program data.

Process-specific stuff, such as the stack area, the CPU registers, the
data area, et al are, of course, not shared (unless you are talking about
threads, in which case the data area is shared among threads).

Stated again for repetitive effect: Simply sharing a shared library code
page in the virtual memory system of a win32 OS does _not_ imply any kind
of reentrancy issues....

I don't know of any single win32 library call that is claimed to not be
reentrant across different applications (read: processes) running
concurrently on the same system.  Do you?

>
> > Your thesis is that multiple applications (processes) that 'use the same
> > library' could possible step on each other's toes.  Even if this were
> > true, this is _not_ reentrancy.
> >
> > Reentrancy has to do with whether or not two or more threads of the same
> > running process are allowed to safely (meaning without corruption)
> > 'enter' the same function at the same time.
>
> As I explain above, at least in the Windows documentation I read,
> "reentrancy" was ALSO used of libraries shared between applications at the
> system level (thus, the ones part of Windows that were re-written to take
> this into account and/or fully separated into unique copy for each app,
> for the NT series, and the the context of the discussion in which I was
> reading about reentrancy). particularly in the "copy on write" general
> system architecture of W9x.

NT also does copy on write, as does Linux.

>
> However, that's arguing terminology, and I will definitely admit that I

Well I was arguing termonology actually.  I objected to the use of the
term reentrancy to describe something other than reentrancy.

> know nothing about the internals of the GTK libraries, and CERTAINLY
> nothing about their implementation on the MS proprietary platforms, which
> I left behind for good when I switched to Linux.  Thus, it's entirely
> possible my theory was invalid to the point of absurdity in that
> particular instance.  I'll agree to stipulate that, for the point of this
> discussion.  I'll just say that I was using the term "reentrancy"
> correctly as I'd seen it professionally documented, so my use couldn't be
> /entirely/ incorrect, tho it could certainly simply not apply to the bug
> discussion in this particular instance.

Ok, I will concede that reentrancy has analogues in other realms -- such
as the system as a whole, or even the network environment as a whole, and
not just the threads within one application.

However I still maintain that the term reentrancy is reserved for one
particular concrete concept.  You don't want to use the term 'reentrancy',
but use some other term -- even if the analogy to reentrancy is strong in
your mind.  Using the term reentrancy misleads people because it is a term
reserved for API/programming semantics.

And you are not alone.  This term is misused a lot, actually.

>
> > Two separate apps in windows that use the same dll, even if that dll
> > isn't 'reentrant' will never ever ever step on each other's toes.  This
> > is because each windows process gets its own copy of the initialized and
> > uninitialized data that came with the library... so all initialized and
> > uninitialized data that goes with the .dll is private to each program,
> > living on separate memory pages, and completely unaware of the other
> > instances of that running library.
>
> See above.  That is indeed the case with libraries as handled by the NT
> series kernel.  However, in pre-XP "Consumer Windows", that wasn't always
> the case, which is where much of my familiarity with the concepts involved
> enters the picture, as my source was a discussion of the robustness at the
> sacrifice of memory of the NT series kernels as compared to 9x.

Really?  Are you absolutely sure?  I can't think of one of the many common
windows .dll's that isn't 'reentrant' (I use quotes here because I am
misusing the term purposely) with respect to different processes... can
you please name one?

>
> > However, you could be correct in that this situation could be caused by
> > resource contention, but I wouldn't look to the GTK dll necessarily, but
> > rather to an issue possibly inside the windows kernel.  Certain hardware
> > resources scale poorly.  Especially with the non-NT branch of windows
> > implementations.
>
> Absolutely agreed.  Perhaps I should have specifically mentioned I was
> discussing this as an example of one thing that could go wrong in
> inter-process resource contention, while there are all sorts of others
> equally, or as you point out, far more likely, to be the problem.
>

My only qualm with what you said was an apparent misuse of the term
reentrant, which is typically used to describe functions or subroutines
that cannot be relied upon for execution by multiple threads in the same
program.  Use of this term in a way broader than that is misleading....
however I do conced that many people misuse this term.

-Calin