[ic] Re: interchange and thread enabled Perl

[Mike Heins]

Quoting Toni Mueller (support-ic@oeko.net):

[snipping routinely below]

> > It appears that Perl 5.8.0's ithread implementation is much better than
> > previous ones, which wouldn't even begin to run Interchange properly.
> 
> So the statement "Interchange doesn't even start" relates to 5.6.1
> exclusively?

Who knows? It is undefined. I made no studies of thread-enabled
Perls -- the few times someone showed up on the list with one
we had them build a non-threads Perl and the problem went away.

> > Red Hat distributed their perl for 8.0 and 9.0 with threads enabled,
> > which is *not* the default. This is an extremely bad decision; the
> 
> Well, it is likely to become the default pretty fast, but you seem
> to suggest that I badger the guy who made this decision to get him
> reverse it.

I don't expect you to have any effect, and RHL 9.0 is out so the point
is really moot.

> 
> > than one in 1,000, and anyone seriously using such a program must keep
> > up with the latest builds and modules to fight bugs.
> 
> This sounds like being only an option for full-time Interchange
> developers and administrators, iow, "don't".
> 
> > In fact it sometimes seems as if the Python-heads there are trying to
> > sabotage Perl. I don't think that is the case; but there is no rational
> 
> Do I understand correctly that Python threads are considered stable,
> and that you mean that this is an incentive to switch or keeping
> people away from Perl?

I don't know the state of threads in Python, and don't really care. 8-)
To me, threads in UNIX are a buzzword much more often then they are
a reality. Only a very few programs need them because UNIX process
management is now so lightweight. This is not true on other OSes
I could name.

> > reason to enable threads on Perl unless you are doing thread-based 
> > program development. I know of no such programs in the Red Hat
> > distribution; it would surprise me greatly if there are any.
> 
> If you are right - very likely - I guess that it was done for
> educational reasons: Get people to see their stuff break...

When you have companies relying on Red Hat Linux more and more,
I would find a decision like that to be immensely stupid. Perl is
not a toy; there are thousands of serious programs which use it.

[snip] 
> > practical. Leaving aside the work that would need be done on Interchange
> > itself, IC uses or can use dozens of other Perl modules, each of which
> > would need to be vetted. The types of problems caused by defects in
> > threadsafeness (sic) are also notoriously hard to debug.
> 
> Granted.
> 
> For a start, it would be sufficient if Interchange just were thread
> safe.

Perhaps people don't understand. This is NOT a fault of Interchange!
The way threads are supposed to work is that if they are not explicitly
called, they are supposed to have no effect. In other words, if you
don't want to make your program thread-safe you don't have to. A Perl
built with threads that causes a program to fail when it does not fail
with Perl not built with threads is a buggy Perl.

That being said, we have been slowly improving our capability in this
area. Because of PreFork mode, which can mean the same process can
run hundreds of page transactions without re-forking, we have been
finding and fixing problems with variable initializations being
impacted by the code. Have we got them all? Almost certainly not. But
it seems to be pretty good, and getting into habits like these are the
same habits you need to get into WRT thread-safeness.

But I find it remote that Interchange will use threads ever. It is
not the type of program where it makes much sense to do so.

>  I don't know how hard this might be to achieve, or where to
> look, however.

It isn't worth doing at this point. There are many more higher-priority
things.

-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.513.523.7621      <mike@perusion.com>

There's nothing sweeter than life nor more precious than time.
-- Barney