[Tutor] Threading...

[Kent Johnson]

On Mon, Apr 27, 2009 at 9:29 AM, A.T.Hofkamp <a.t.hofkamp at tue.nl> wrote:
> Kent Johnson wrote:
>>
>> On Mon, Apr 27, 2009 at 2:46 AM, A.T.Hofkamp <a.t.hofkamp at tue.nl> wrote:
>>>
>>> you are making
>>> a IO-bound app, so threading doesn't buy you anything in performance and
>>> gives a big headache in data protection

Perhaps I misinterpreted this. Do you mean "threading doesn't buy you
anything in performance" vs Twisted or vs his current solution? Vs
Twisted, I would agree. Vs single-threaded, I disagree, especially
given the OP's stated goal of opening a lot of concurrent connections.

>> Please explain. Presumably the single-threaded app is not IO-bound.
>> Adding threads can push it to the point of being IO-bound. The

> As far as I know, doing DB queries is an IO-bound process, since you must
> make a connection to the remote DB server, and send data back and forth to
> the server over the network (which is ssssllllooooowwww compared to a
> calculation).

>From the point of view of the client, there is likely to be a fair
amount of dead time, waiting to establish a network connection,
waiting to establish a database connection, waiting for the db to do
it's thing. So my assumption is that the original, single-connection,
single-threaded client is neither IO- nor CPU-bound, it is spending at
least some time just waiting.

In this scenario, both threads and Twisted can help to increase the
load on the remote server by more fully utilizing the available IO
bandwidth. That is what I meant by using threads to create an IO-bound
app.

> With threading, you will have more network connections that you are waiting
> for. W.r.t. performance you don't gain anything, since the CPU is already
> mostly idle.

You will get more performance if the threaded app is able to use the
dead time in the IO. ISTM this directly addresses the OP. His stated
goal is "to throw a ton of open connections at" the DB. Certainly he
can do that using threads.

>> requirements for communicating between threads in this app are modest

> With Twisted, you can have at least the same number of IO connections as
> with threading, while you don't get the data protection problems and
> overhead for the simple reason that it is still a single-threaded program.
>
>
>
> Maybe threading is the correct solution here. However the OP also asked for
> "...or is there another way to go about it?".
> Twisted is definitely another way to go about it, and nobody mentioned it in
> previous posts, so I thought it correct to mention its existence here.

I don't dispute that at all.

Kent