I searched few post here, and some other group, but I think, Concepts
of Connection pooling is discussed very little.

having some basic query.

1. creating N thread, every thread blocks on accept,  do some work,
close connection and again accept  (Richard Stven's TCP PreThreaded
Server, per-Thread accept)

can this be considered as  connection pool ?

*** thread is closing  fd return by accept and doing new accept
without calling pthread_exit,***


--Raxit

[ Post a follow-up to this message ]

"Sheth Raxit" <raxitsheth2000@yahoo.co.in> writes:
> I searched few post here, and some other group, but I think, Concepts
> of Connection pooling is discussed very little.
>
> having some basic query.
>
> 1. creating N thread, every thread blocks on accept,  do some work,
> close connection and again accept  (Richard Stven's TCP PreThreaded
> Server, per-Thread accept)
>
> can this be considered as  connection pool ?

I think 'thread pool' would be more appropriate. Insofar I know it, a
'connection pool' is something intended to facilitate reuse of
already established connections to some database server.

[ Post a follow-up to this message ]

On Mar 26, 3:12 pm, Rainer Weikusat <rainer.weiku...@sncag.com> wrote:
> "Sheth Raxit" <raxitsheth2...@yahoo.co.in> writes: 
> 
> 
> 
>
> I think 'thread pool' would be more appropriate. Insofar I know it, a

Sorry for confusion...It is thread pool but is it connection pool
tooo.

or better  when creating connection pool, is it very simillar , as i
described here. (It may or may not be thread pool,but mostly it is) or
it is fundamentally different ?




> 'connection pool' is something intended to facilitate reuse of
> already established connections to some database server.

--Raxit

[ Post a follow-up to this message ]

On Mar 26, 3:48 am, "Sheth Raxit" <raxitsheth2...@yahoo.co.in> wrote:

> Sorry for confusion...It is thread pool but is it connection pool
> tooo.

It is neither a thread pool nor a connection pool. It is not a
connection pool because it does not create more than one connection
and then assign tasks that require a connection an available
connection. It is not a thread pool because it does not create more
than one thread and then assign tasks that require a thread to an
available thread.

I suppose you could argue that it is sort of a thread pool, with
'accept' being the job assignment function and jobs being dispatched
to the pool by making connections. It certainly is not the typical
thread pool because the whole point of a thread pool is to assign jobs
to threads cheaply, and having to do a connection setup and tear down
for each job is not cheap.

DS

[ Post a follow-up to this message ]