On Wed, 2008-01-09 at 21:13 +1300, Amos Jeffries wrote: > Alex Rousskov wrote: > > On Tue, 2008-01-08 at 16:19 +1300, Amos Jeffries wrote: > > > >> As you say this is headed toward SMP/threading and that may cause any of > >> the scheduled steps to be run simultaneously or in a different order. > > > > We will cross that bridge when/if we have to. For now, the order of > > async events firing is guaranteed to be the same as their scheduling > > order. A lot of Squid code depends on that guarantee. > > You seem to have slightly missed my point. > That this code is currently depending on that implicit guarantee when it > should not be. This change is the perfect time to drop that implicit > dependency and make it clean (bug free!).
The only relevant dependency/guarantee is that the file descriptor is closed after all corresponding callbacks are called. That dependency/guarantee cannot be removed (or, at least, it is not AsyncCall job to do that). The order of handler calls should not be important in the context of this email thread (and yet AsyncCall work does not change the old order). > Having one precursor call > schedule its successor is the cleanest and fastest way to do that. In this particular case, there is no precursor or successor. Comm simply notifies all interested parties that the FD is about to be closed. Also, do not forget that comm does not know when a given async call is fired. The caller is not notified when its call fires and the called handler completes. > > I do not know what async-reversable is, but I think what you propose is > > practically equivalent to Christos code because async events never get > > out of order. > > async-reversable is when things happening asynchronously CAN get out of > order. And in wort case occur in reverse order of scheduling. > > Async generally means the thread/call/job is completely independant on > any other currently scheduled. Any dependency make the dependent jobs > synchronous regarding each other. I would like to avoid talking in depth about true asynchronous execution for now, but I believe you are mixing two distinct properties: asynchronous execution of jobs and preservation of call order originating from a single job. In many environments, asynchronous jobs are guaranteed that their calls will not be reordered. Again, I do not think we should spend much time on this currently-theoretical discussion because a lot of old Squid code depends on call order preservation and AsyncCall work will not change that dependency at this time. > Squid is fast heading towards a state where the async queue might easily > be split between processors. That means several fast finishing calls > scheduled after a single slow-finishing might be run before the > slow-finishing is done. Let's talk about this when/if we actually decide to split async queue between processors. We are not creating more work by not addressing these questions now. > > The only difference I can imagine is that in your scheme, a handler > > called earlier (in step 2) can schedule another/new async call that will > > be executed before handlers called in step 3. This should not make a > > difference for correctly written handlers. > > The case which started this thread is a case in which the execution > timing of (3) *does* effect other calls/handlers. Not exactly. The problem was with the order of FD closing (which was not an async call) and all async calls. We do not have that problem after Christos moved FD closing into an async call handler (which is scheduled last). > Maybe I'm getting confused but your argument was that each async call is > self-complete in state yes? The call is, but the handler (job) may not be. Adrian was asking about the call, not about the handler that the call triggers. Clearly, lots of current handlers/jobs share state with other handlers/jobs. > Keep state-automata in a mult-dimensional threaded environment etc. in > mind during the current designs and they won't need re-designing next > year when its implemented. Currently, we are replacing a large set of custom sync calls with a unified async call interface. The next step would be to address truly asynchronous execution of jobs. We are not creating a lot of extra work by not doing that second step now; we are just postponing future work. This should allow us to reap important AsyncCall benefits such as robustness and easy of debugging without spending many more months on supporting truly async jobs. > The calls for SMP support and threading in squid should not be as huge > an overhaul as IPv6 was. It should be possible after async is merged to > link some threading library and incrementally turn each async call into > an independent thread. A call is just a message exchanged between jobs. Jobs may become independent threads, but calls will not. Cheers, Alex.
