Re: client_side and comm_close

lör 2008-04-19 klockan 23:05 -0600 skrev Alex Rousskov:
> It is easy to implement two kinds of call scheduling, but I am not sure
> I understand the merits of doing so. What do you mean by the "event
> loops" in this context? Are you talking about eventAdd() queue? Or I/O
> event (i.e., comm) callbacks? I am guessing it is the latter.

Both. The event checks (I/O, timed events etc) run from the main loop
and are always the first AsyncCall callers for anything going on.

> The immediate calls from comm were not really "safe" (because of the
> recursive/reentrant behavior) so I am not sure what we would achieve
> here.

As everything going on in Squid is initiated by the event loop you don't
get recursion from this change..

main loop -> event loop -> immediate async call -> handler -> other I/O
actions etc but from here always async..

> I hope answers to earlier questions would clarify the intent.
> Again, I would like to understand and agree on the problem/goal before
> debating specific solutions...

Goal is to get a clean and deterministic API for the event processing
without hard to reproduce race conditions.

> Please clarify which of the following comm_close implementation would
> solve the problems you want to solve in this context:
>
> A) Immediately call all not-yet-dialed callbacks for the affected FD.
> All relevant I/O callbacks are called with ERR_COMM_CLOSING flag set (if
> we still have that). The closing callbacks, if any, are called last.
>
> B) Asynchronously call all not-yet-dialed callbacks for the affected FD.
> All relevant I/O callbacks are called with ERR_COMM_CLOSING flag set (if
> we still have that). The closing callbacks, if any, are called last.
>
> C) Other.

Don't call them. See ERR_COMM_CLOSING discussion.

The I/O calls are no longer relevant at the moment the fd has been
semantically closed (comm_close called by the code). Only the close
callbacks matter at that time.

Note: The close callbacks as such need to be async, just not the closing
of the fd (or at least at a semantical level).

Regards
Henrik
Received on Tue Apr 22 2008 - 13:13:25 MDT