[tor-bugs] #5263 [Tor Relay]: Busy/infinite Libevent loops
Tor Bug Tracker & Wiki
torproject-admin at torproject.org
Mon Mar 5 16:05:39 UTC 2012
#5263: Busy/infinite Libevent loops
------------------------+---------------------------------------------------
Reporter: robgjansen | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: Tor: 0.2.2.x-final
Component: Tor Relay | Version:
Keywords: | Parent:
Points: | Actualpoints:
------------------------+---------------------------------------------------
Changes (by robgjansen):
* cc: jansen@… (added)
Comment:
> >The reason that both read and write events are both de-registered when
the marked connection can not flush is because both result in the same
behavior. Both read/write events on marked connections will never again do
any actual reads/writes, and are only useful to trigger the flush and
close the connection.
>
> I think I agree with this patch except for this question. Is it really
the case that we reach this point with the connection still reading? Keep
in mind that this case can only happen if the connection is marked and is
busy flushing; a connection in that condition *shouldn't* be reading.
Did you run into some that were? If I missed something, though: sz==0 in
that case doesn't mean that read is blocked on bandwidth; no read was
attempted in the code above, and the read bucket wasn't examined.
>
> Can you tell me more about the read case here?
I did run into a case where a connection was reading.
You are technically correct about sz==0 not implying read is blocked on
bandwidth. The reason I added that was to catch reading connections that
are flushing but not registered as writing, because we need a way for the
event to later get activated, flushed, and removed. Would it be better to
remove the read event and set write_blocked_on_bandwidth to get ensure
removal later?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5263#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list