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

[Duncan]

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
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
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.

> 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.

However, that's arguing terminology, and I will definitely admit that I
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.

> 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.

> 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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin