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

[Calin A. Culianu]

On Sun, 21 Sep 2003, Duncan wrote:

> > On Windows, I think the problem became less frequent (from always/almost
> > always to often/sometimes) after upgrading GTK+ from 2.2.3 to 2.2.4.
>
> I was thinking it might be a charset issue.  W2K supports the theory,
> since it runs unichar I believe.  Do the filter failures possibly have
> accents or umlauts or some such thing in some languages, but possibly not
> as displayed in the font being used?  I'm guessing it might not be
> matching because it literally doesn't match, since they are different
> characters based on character-set.
>
> > Last time (with GTK+ 2.2.4) I also observed another app (a compiler)
> > freezing while Pan was stuck filtering.  When I terminated Pan, the other
> > app was running again.
>
> This looks like a resource contention issue.  Some sort of thing where
> application A is using X but can't continue until it gets Y, but
> application B has Y and can't continue until it gets X, with both X and Y
> being single use objects or non-reentrant code, meaning a deadlock
> situation.  NT and successors are /supposed/ to be designed as fully
> reentrant, and with individual apps each getting their own exclusive copy
> of "single use" items, but as we all know, theory and practice aren't
> always the same, except in theory.  <g>
>
> If that's indeed what it is, presumably in code having to do with
> charset conversion based on the above, killing the one app would free the
> resource needed by the other app, so it could continue normally.
>
> You don't mention what compiler it was or what it was compiling, but it's
> possible both PAN (or rather more likely the GTK language library
> functions) and the compiler were contending for the same code segment,
> altho MS apps say wouldn't because they don't generally use said code
> segment, which is there for "legacy and compatibility" reasons, but not
> something they regularly use. (Or, it might be used in devel, but not
> commonly otherwise, and they figure its not likely you'd be trying to
> compile multiple apps at the same time..)
>
> In this scenario, the old GTK version may have not used it correctly, so
> caused issues due to that, while the new one makes better use of it so
> doesn't malfunction as often, but does tie down the resources now causing
> the occasional conflict with anything else that happens to try to use the
> resources in reverse order when they both happen to try to access the same
> shared library/system code at the same time.
>
> That's a lot of supposition, I will admit, but it's plausible..

Sorry for being a jerk, but:

Uhhh, not only implausible, but likely impossible.

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

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.  Or more precisely, if one thread is
in a function/subroutine, will another thread entering the same subroutine
(before the first thread exits the subroutine) possibly corrupt the
correctness of that subroutine's (or program's) computation?  The answer
to this, with a few rare exceptions, is usually 'no' unless the function
itself uses static data.

At any rate, that's reentrancy, and a compiler freezing while Pan is
running is not an example of an issue related to reentrancy.  At least not
reentrancy of the GTK library.

This is because 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.  This is what it means to be
a shared library.  If this were not the case, static libraries would
behave differently from shared libraries, which would mean that the whole
world would be a really stupid place to live in for the application
programmer...

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.