Whoa, full stop!
Why are we planning on checking in something that we know is going to
break a major piece of functionality for over a week? Who's going to
approve that checkin? I'd like to hear their justification for making
dogfood inedible for a week.
-j
Doug Turner wrote:
> yeah, see: <http://bugzilla.mozilla.org/show_bug.cgi?id=65220>
>
> http://bugzilla.mozilla.org/show_bug.cgi?id=65220
>
> The problem is that nsIChannel's are not bidirectional (eg you can not
> read and write at the same time even if you are lockstepping). In
> FTP, I do a AsyncRead while doing a AsyncWrite. Things should be
> okay, but they are not. The write socket transport is stuck in the
> select list resulting in the sockettransport going into a busy waiting
> state. I am working on fixing nsIChannel and all callers and should
> be done with it in a week or so. (I estimated a week, but I think i
> may run over because some of the terrible usage patterns I am finding).
>
> Furthermore, Darin will be landing some AsyncWrite (and friends)
> changes today which will definitely break FTP. This breakage will be
> fixed my may nsIChannel changes.
>
> We should probably disable the ftp test on tinderbox for the next week
> or so.
>
> CC-ing the netlib newsgroup.
>
>
>
> [EMAIL PROTECTED] wrote:
>
>> That was doug.
>>
>> >
>> > These timeouts starting with a major ftp checkin. Don't remember
>> who did
>> > it, but it was some kind of minor carpool.
>> > Due to the slowdown, the corresponding bug got reopened, but
>> obviously
>> > not fixed :-(.
>> >
>> > Axel
>>
