Threads + Re(gex) Baffled!?!?!?
Cliff Daniel
cdaniel at Level3.net
Thu Sep 16 01:08:24 EDT 1999
Problem found... read below.
Tim Peters <tim_one at email.msn.com> writes:
> If that code is really at top level, Reply, tmp, line and m are shared vrbls
> and the code isn't thread-safe. That's a problem with looking at program
Nah, I just posted pseudo code. I should have clarified that all variables
were actually local.
> Two things odd about that:
>
> 1) You're still calling re ("tmp = re.split(..."). (BTW, use string.split
> for this -- faster and clearer)
I have no idea why i used re.split(). I always use string.split(). Well
for giggles I changed it to string.split() and altered nothing else. Guess
what? The cpu/kernel never went above 2%. Problem resolved. What the
heck?
> 2) re knows nothing about threads; there are no locking, or any other
> thread-aware, operations in it. It seems to have been coded to be
> thread-safe, but Python isn't exploiting that at present. So wrt threads
> it's exactly like any other random chunk of thread-unaware C code in the
> implementation: it runs single-threaded by virtue of Python's global
> interpreter lock. So if you're having a problem with re, you'll most likely
> have the same problem with any piece of C code.
re may know nothing about threads but the simple fact that re.split is
doing something horrible on this platform versus what string.split does.
What's strange is that it was only affected by re.split() and not some
other random piece of C code.
> The bad news is that, so far, there's nothing here to suggest you wouldn't
> have exactly the same symptoms running single-threaded straight C code. We
> need more info before suspecting Python is compelling, or you need to find a
> wizard for your flavor of Solaris threads.
The problem didn't exist with one thread. As you increased the threadpool
the problem grew.
Either way, thanks for your responses!
Regards,
Cliff
More information about the Python-list
mailing list