Threads + Re(gex) Baffled!?!?!?

[Cliff Daniel]

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