On Tue, 13 Oct 2009 00:29:56 +0200, Henrik Nordstrom <hen...@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
