Re: connection pooling

Thomas Jacob wrote:
> What makes you say that? Where is the significant difference between the
> pleasantness of threading on Windows and Unix (pthreads)? Especially on Python?
>   

Part of it is philosophical.  Threading on Windows is rather easy, being
a fundamental part of the kernel.  Pthreads forces me to worry about a
lot of details that I don't really care to worry about.  It just doesn't
seem as natural, and that's may be because it began life as a wart
bolted on to the side of traditional multiprocessing.

It's possible I just haven't found the right abstraction yet.  I pull my
hair out every time I have to managed shared data in Linux threading,
because the event/mutex abstraction doesn't make sense to me.  It isn't
natural.

I grant the point about Python.

> I think you're mixing up cause and effect here. Programming with threads is much more
> difficult and error prone than working with multi-process systems (or using
> something like Twisted for that matter), regardless of OS.

That's really a matter of opinion, and it's an opinion I would disagree
with.  That doesn't mean you aren't entitled to it, however.  ;)

> Threads are also a relatively recent arrival. So why convert easily understood
> and stable designs to something with lots of potential problems? Performance
> is almost a none issue given copy-on-write pages and the fork system call.
>   

Absolutely.  Look, I'm not saying "threading is unconditionally the best
solution, Windows does it better, therefore Linux sux."  Not at all. 
I'm saying that, in general, "threading is better on Windows and
multiprocessing is better in Linux, and that difference strongly affects
application architectures."  The original poster was questioning the
need for connection pooling, based partly (in my view) on the assumption
that multiple connection applications were always implemented with
threads.  That assumption is wrong, and I was trying to point out why.

> Windows 2000 is relatively young and doesn't have good support and performance
> for multiprocess archictetures (and no fork), also threading was built in from day one, 
> so there wasn't and isn't really any alternative to threading. Incidentally
> that's why many multiprocess Unix apps perform so badly when ported to Windows, whereas
> in the reverse direction you don't lose as much (Threaded on Windows => threaded
> on Unix).
>   

Much of what you say has merit, and I probably should have worded it
differently.  The bottom line is that the two systems really need
different approachs.  Threading is the natural solution on Windows, and
multiprocessing is the natural solution on Windows.

The maturity thing is a bit of a red herring.  Threading was not
introduced in Windows 2000; it was originally introduced in Windows NT
3.1 in 1993, and the Win32s addons to Windows 3.1 in 1994.  That
certainly is "relatively young" compared to Unix, but it is
significantly more mature than threading on Linux.

I probably should have avoided the whole topic...

-- 
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.