Re: client_side and comm_close

2008-04-20 Thread Alex Rousskov
On Sun, 2008-04-20 at 11:47 +0800, Adrian Chadd wrote: Yes, then you left it by introducing something which exposed the bugs. The problems this thread is discussing were known before AsyncCalls. But they weren't exhibiting as -bugs-. They were: assertion in bug2309 (and many other

Re: client_side and comm_close

2008-04-20 Thread Henrik Nordstrom
lör 2008-04-19 klockan 21:01 -0600 skrev Alex Rousskov: I agree with many of your specific suggestions (and will discuss them separately), but I want to understand what problem you are proposing to solve first. For example: - Fix a few new bugs introduced by async calls. - Fix certain comm

Re: ERR_COMM_CLOSING and comm API changes

2008-04-20 Thread Henrik Nordstrom
lör 2008-04-19 klockan 22:14 -0600 skrev Alex Rousskov: FWIW, I have always wanted to get rid of COMM_ERR_CLOSING in Squid3 :-). A close callback is sufficient to let the FD user know that there will be no more callbacks for that FD. Yes. With some effort, we may be able to pragmatically

Re: client_side and comm_close

2008-04-20 Thread Alex Rousskov
On Sun, 2008-04-20 at 09:22 +0200, Henrik Nordstrom wrote: 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

Re: client_side and comm_close

2008-04-20 Thread Tsantilas Christos
Maybe it can be easier: Just keeping the comm_close as is and in AsyncCallsQueue just cancels/not execute asyncCall's for which the fd_table[fd].flags.closing is set. We only need a way to identify comm_close handlers and the asyncCall which will do the actual close of the socket. Alex

Re: client_side and comm_close

2008-04-20 Thread Henrik Nordstrom
sön 2008-04-20 klockan 22:19 +0300 skrev Christos Tsantilas: The important files are the CommCalls.* AsyncCalls.* and ICAP/AsyncJob.* But I believe that you are understand it enough. I think I understand most of the code now, but not entirely 100% sure on the design and intended use model

Re: Where to document APIs?

2008-04-20 Thread Henrik Nordstrom
sön 2008-04-20 klockan 22:14 -0600 skrev Alex Rousskov: The current suggestions are: .dox (in docs/Programming Guide or in src/, not clear) -- Amos. .dox (in src/) -- Kinkie. .h (or perhaps .cc) -- Henrik. To clarify: Longer API documents, .dox file in docs/, or maybe src/ next to the .cc

Re: Where to document APIs?

2008-04-20 Thread Amos Jeffries
On Thu, 2008-04-17 at 17:53 +1200, Amos Jeffries wrote: Alex Rousskov wrote: Hello, Recent Squid3 discussions mentioned a set of rules or guarantees for AsyncCalls and Comm APIs. Where do you think these things should be documented? * Source code, header files: More chances to

Re: client_side and comm_close

2008-04-20 Thread Henrik Nordstrom
sön 2008-04-20 klockan 22:56 -0600 skrev Alex Rousskov: - I hope we can avoid similar problems with comm_cancel_read because the two or three places using that call can be adjusted to cancel the read callback directly. We have already talked about that elsewhere. It's not only

Re: Where to document APIs?

2008-04-20 Thread Amos Jeffries
On Mon, 2008-04-21 at 00:55 +0200, Henrik Nordstrom wrote: sön 2008-04-20 klockan 12:23 -0600 skrev Alex Rousskov: At this point, I am interested in collecting formal API guarantees, not writing a true Guide, but it feels like .dox files should go into doc/Programming-Guide. Shouldn't

Re: Where to document APIs?

2008-04-20 Thread Amos Jeffries
sön 2008-04-20 klockan 22:14 -0600 skrev Alex Rousskov: The current suggestions are: snip .h (as a second-best as .dox in src/) -- Amos .dox (in src/) -- Kinkie. .h (or perhaps .cc) -- Henrik. To clarify: Longer API documents, .dox file in docs/, or maybe src/ next to the .cc Basic

Re: client_side and comm_close

2008-04-20 Thread Alex Rousskov
On Mon, 2008-04-21 at 15:48 +1200, Amos Jeffries wrote: comm_close(fd) API: 1) No I/O callbacks will be dialed after comm_close is called (including the time when comm_close is running). Sounds good. 2) All close callbacks registered before comm_close was called will be called

Re: client_side and comm_close

2008-04-20 Thread Alex Rousskov
On Mon, 2008-04-21 at 16:02 +1200, Amos Jeffries wrote: On Sun, 2008-04-20 at 22:01 +0300, Tsantilas Christos wrote: Maybe it can be easier: The ease of implementation is a separate question. We still have to agree what we are implementing, and the items below attempt to define that.