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.
>
>> 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
Received on Tue Oct 13 2009 - 00:33:07 MDT
This archive was generated by hypermail 2.2.0 : Tue Oct 13 2009 - 12:00:06 MDT