On Tue, 13 Feb 2001, Ben Tilly wrote:

> If you internally multithread this, then you now get race conditions where
> the database handle is switching between serving thread A and thread B,
> both of which are doing operations involving a table #tmp that each was
> expecting to create, manipulate, then tear down...

Hi Ben,

This is an old topic but this article reminded me of it...

  http://www.tech-report.com/columns/ryu/2001q1/smt/

More information is available here:

  http://www.cs.washington.edu/research/smt/

This is more along the lines of what I was proposing, along with taking
advantage of the higher level information that Ruby source provides (as
opposed to a stream of assembly opcodes).

Please note how SMT does benefit single threaded applications. This is
the angle which I was trying to get across with the talk about implicitly
multithreading calls. I wasn't proposing having hidden Thread.new's.

I'm pleased to see that one of my dark lurking concepts has actually
been explored, though I can't claim to have invented it anymore. :)

-- 
  spwhite / chariot.net.au