Alex Rousskov wrote:
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
Alex Rousskov wrote:
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
On Mon, 2008-04-21 at 23:45 +1200, Amos Jeffries wrote:
IMO, The proposed API _very_ first two lines of code in comm_close are to
register a special Comm callback to perform the fclose() call, and then to
immediately set fd_table flag closed for the rest of the comm_close
process.
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
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
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
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
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
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
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
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.
fre 2008-04-18 klockan 08:25 -0600 skrev Alex Rousskov:
The changes needed on the client-side are pretty much unrelated to async
calls. Async calls just make the design problems more obvious and help
in solving them. Removing async calls from comm will fix a few bugs, but
will be a step
On Sat, Apr 19, 2008, Henrik Nordstrom wrote:
I don't remember why comm_close was made async, but the more I think
about it I think it's most likely wrong. comm_close SHOULD invalidate
any pending comm operations on that fd, anything else just leads to
nightmares.
The back-end of
Hi all,
I think we have two different problems here, the client_side code and
the comm_close in async calls.
If I am not wrong the bug which triggered this discussion is the bug2309
which is squid3.0 bug where AsyncCalls does not exists. The problem here
is the client side code which the true
On Sat, 2008-04-19 at 10:50 +0800, Adrian Chadd wrote:
On Fri, Apr 18, 2008, Alex Rousskov wrote:
If the client_side's main problem was a few coding bugs caused by async
call changes, you may have been right. Unfortunately, our main problem
here is the client_side design flaws. Removing
On Sat, 2008-04-19 at 11:52 +0200, Henrik Nordstrom wrote:
fre 2008-04-18 klockan 08:25 -0600 skrev Alex Rousskov:
The changes needed on the client-side are pretty much unrelated to async
calls. Async calls just make the design problems more obvious and help
in solving them. Removing
On Sat, Apr 19, 2008, Alex Rousskov wrote:
But now you have a better understanding of the bugs that are introduced
with AsyncCalls. You can then plan design changes to the client-side code
to work around these.
I am not sure how to rephrase this so that it is clear, but client-side
On Sat, 2008-04-19 at 11:52 +0200, Henrik Nordstrom wrote:
fre 2008-04-18 klockan 08:25 -0600 skrev Alex Rousskov:
The changes needed on the client-side are pretty much unrelated to async
calls. Async calls just make the design problems more obvious and help
in solving them. Removing
On Sat, 2008-04-19 at 17:24 +0300, Tsantilas Christos wrote:
I think we have two different problems here, the client_side code and
the comm_close in async calls.
You are correct. General async call bugs and general comm API problems
have been mentioned on this thread as well. Most of these
Alex Rousskov wrote:
On Fri, 2008-04-18 at 15:40 +1200, Amos Jeffries wrote:
IMO, This should be queued as part of the 3.1 cleanups, but not as
urgently as some other issues.
The priorities as I see them now are:
- immediately fixable and urgent bugs.
- completing the dedicated 3.1
On Wed, Apr 16, 2008, Alex Rousskov wrote:
In short, we have several related problems here: (a) client_side code is
incapable of reliably identifying whether comm_close has been called;
(b) ConnStateData::isOpen may not work anymore; (c) client_side code
uses many different ways to identify
On Fri, 2008-04-18 at 18:34 +1200, Amos Jeffries wrote:
Alex Rousskov wrote:
On Fri, 2008-04-18 at 15:40 +1200, Amos Jeffries wrote:
IMO, This should be queued as part of the 3.1 cleanups, but not as
urgently as some other issues.
The priorities as I see them now are:
-
On Fri, 2008-04-18 at 16:15 +0800, Adrian Chadd wrote:
On Wed, Apr 16, 2008, Alex Rousskov wrote:
In short, we have several related problems here: (a) client_side code is
incapable of reliably identifying whether comm_close has been called;
(b) ConnStateData::isOpen may not work anymore;
On Fri, Apr 18, 2008, Alex Rousskov wrote:
I'd suggest another option - roll back all of the async calls changes to the
comm code, stabilise the codebase without it and re-evaluate what should
occur (in smaller chunks, rather than dropping in a new comm manager)
before reintroducing it.
Hi all,
Alex Rousskov wrote:
In reply to comment #8 for bug #2309
comm_read assertion failed: ccb-active == false
http://www.squid-cache.org/bugs/show_bug.cgi?id=2309
Note to the one looking into this bug: The assert happens if a
comm_read() is called while there already is a comm_read()
On Thu, 2008-04-17 at 20:13 +0300, Tsantilas Christos wrote:
Alex Rousskov wrote:
In reply to comment #8 for bug #2309
comm_read assertion failed: ccb-active == false
http://www.squid-cache.org/bugs/show_bug.cgi?id=2309
Note to the one looking into this bug: The assert happens if a
Alex Rousskov wrote:
On Thu, 2008-04-17 at 20:13 +0300, Tsantilas Christos wrote:
Alex Rousskov wrote:
In reply to comment #8 for bug #2309
comm_read assertion failed: ccb-active == false
http://www.squid-cache.org/bugs/show_bug.cgi?id=2309
Note to the one looking into this bug: The assert
On Fri, 2008-04-18 at 15:40 +1200, Amos Jeffries wrote:
IMO, This should be queued as part of the 3.1 cleanups, but not as
urgently as some other issues.
The priorities as I see them now are:
- immediately fixable and urgent bugs.
- completing the dedicated 3.1 feature list (DEVEL is
In reply to comment #8 for bug #2309
comm_read assertion failed: ccb-active == false
http://www.squid-cache.org/bugs/show_bug.cgi?id=2309
Note to the one looking into this bug: The assert happens if a
comm_read() is called while there already is a comm_read() pending.
Yes.
I would suspect
29 matches
Mail list logo
