squid-smp

From: Sachin Malave <sachinmalave_at_gmail.com>
Date: Tue, 13 Oct 2009 07:58:18 -0400

---------- Forwarded message ----------
From: Sachin Malave <sachinmalave_at_gmail.com>
Date: Tue, Oct 13, 2009 at 7:56 AM
Subject: Re: squid-smp
To: Amos Jeffries <squid3_at_treenet.co.nz>
Cc: Henrik Nordstrom <henrik_at_henriknordstrom.net>, Squid Developers
<squid-dev_at_squid-cache.org>

On Mon, Oct 12, 2009 at 8:33 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>
> On Tue, 13 Oct 2009 00:29:56 +0200, Henrik Nordstrom
> <henrik_at_henriknordstrom.net> wrote:
> > fre 2009-10-09 klockan 01:50 -0400 skrev Sachin Malave:
> >
> >> I think it is possible to have a thread , which will be watching
> >> AsyncCallQueue, if it finds an entry there then it will execute the
> >> dial() function.
> >
> > Except that none of the dialed AsyncCall handlers is currently thread
> > safe.. all expect to be running in the main thread all alone.
>
> Which raises the issue of whether to add a second main queue loop for
> thread-safe calls.  Then schedule calls which have been audited and found
> safe to that queue instead of the current main queue. Usage would be low to
> start with but would allow ongoing incremental SMP improvements by
> gradually migrating chunks of code to be thread-safe.
>
> An alternate would be thread-safe the queue and add a flag to say
> particular calls are thread-safe. That would mean walking the queue
> repeatedly looking for them. Which is perhaps less desirable at the start
> of conversion when few calls are threaded. But gains in utility relative to
> the thread-safety progress.
>
> This involves a small amount of extra code in schedule() to flag which
> queue the calls is sent to, and a chunk of extra memory for duplicate queue
> management objects.
>

---------------------------------------------------------------------------------------------------------------
Ok if that is possible then would like to make those changes,  Either
of them will be tried...

One more thing...

Are you thinking about spawning multiple threads or single thread
separated from main is sufficient for handling all scheduled calls.
Here multiple threads means, we could have threads all trying to dial
entries in AsyncCallQueue simultaneously.....
-------------------------------------------------------------------------------------------------------------------------------

>
> >
> >> can we separate dispatchCalls() in EventLoop.cc for that purpose? We
> >> can have a thread executing distatchCalls() continuously
>
> This is an end-goal. Jumping straight there for everything is usually a
> mistake. But good to re-state it anyway.
>
> >> and if error
> >> condition occurs it is written  in "error" shared variable..... which
> >> is then read by main thread executing mainLoop....... in the same way
> >> returned dispatchedSome can also be passed to main thread...
>
> I think I follow. You mean something like the way errno works in the OS?
> Doing that would be a major crutch in Squid. I'd rather have an error
> object per-job (field in the job descriptor object) which the job handlers
> can use according to the job needs.
> Some will result in data sent back to the client, some in a completely
> altered handling pathway.
>
> Amos
>

--
Mr. S. H. Malave
Computer Science & Engineering Department,
Walchand College of Engineering,Sangli.
sachinmalave_at_wce.org.in
Received on Tue Oct 13 2009 - 11:58:25 MDT

This archive was generated by hypermail 2.2.0 : Tue Oct 13 2009 - 12:00:06 MDT