A version of this is in the following fork:
https://bitbucket.org/gustafn/naviserver-connthreadqueue/changesets
So far, the competition on the pool mutex is quite high, but
i think, it can be improved. Currently primarily the pool
mutex is used for conn thread life-cycle management, and it
is
On 27.10.12 15:56, Gustaf Neumann wrote:
> Changing the notification structure (adding a
> connection-thread-queue and extra condition) is a relatively
> small change, compared to general redesign.
i've just implemented lightweight version of the above (just
a few lines of code) by extending the c
On 26.10.12 21:30, Stephen Deasey wrote:
> I was thinking it could work something like this:
>
>
> - driver acquires lock, takes first conn thread off queue, releases lock
>
> - driver thread puts new socket in conn structure and the signals on
> cond to that one thread (no locking, I don't think)
On Fri, Oct 26, 2012 at 11:41 PM, Jeff Rogers wrote:
> Stephen Deasey wrote:
>> .., but I wonder if
>> we're even attempting to do the right thing?
>
> Do we even know what the right thing is? It could be any of
> - ...
> - minimize resource usage
> - adapt to dynamically changing workload
> - ..
On Fri, Oct 26, 2012 at 11:44 PM, Jeff Rogers wrote:
> Andrew Piskorski wrote:
>> On Fri, Oct 26, 2012 at 08:30:26PM +0100, Stephen Deasey wrote:
>>
>>> I was thinking it could work something like this:
>>>
>>> - driver acquires lock, takes first conn thread off queue, releases lock
>>
>> What if
Andrew Piskorski wrote:
> On Fri, Oct 26, 2012 at 08:30:26PM +0100, Stephen Deasey wrote:
>
>> I was thinking it could work something like this:
>>
>> - driver acquires lock, takes first conn thread off queue, releases lock
>
> What if there are no conn threads waiting in the queue?
>
Same as curr
Stephen Deasey wrote:
> Interesting, but I wonder if we're not thinking this through
> correctly. My suggestion, and your here, and Gustaf's recet work are
> all aimed at refining the model as it currently is, but I wonder if
> we're even attempting to do the right thing?
Do we even know what the
On Fri, Oct 26, 2012 at 08:30:26PM +0100, Stephen Deasey wrote:
> I was thinking it could work something like this:
>
> - driver acquires lock, takes first conn thread off queue, releases lock
What if there are no conn threads waiting in the queue?
--
Andrew Piskorski
---
Interesting, but I wonder if we're not thinking this through
correctly. My suggestion, and your here, and Gustaf's recet work are
all aimed at refining the model as it currently is, but I wonder if
we're even attempting to do the right thing?
> So I'm assuming that the available processing power -
On Thu, Oct 25, 2012 at 10:31 AM, Gustaf Neumann wrote:
> I don't think, that a major problem comes from the "racy"
> notification of queuing events to the connection threads.
> This has advantages (make os responsible, which does this
> very efficiently, less mutex requirements) and disadvantage
I started working on some related ideas on a fork I created
(naviserver-queues). The main thing I'm trying to improve is how the
state-managing code is spread out across several functions and different
threads.
My approach is to have a separate monitor thread for each server that
checks all t
I don't think, that a major problem comes from the "racy"
notification of queuing events to the connection threads.
This has advantages (make os responsible, which does this
very efficiently, less mutex requirements) and disadvantages
(little control).
While the current architecture with the
On Wed, Oct 10, 2012 at 9:44 PM, Jeff Rogers wrote:
>
> It is possible to get into a situation where there are connections
> queued but no conn threads running to handle them, meaning nothing
> happens until a new connection comes in. When this happens the server
> will also not shut down cleanly
13 matches
Mail list logo
