- From: Michel Philip <philipm@altern.org>
- Date: Tue, 18 Dec 2001 06:28:39 +0100
- To: www-lib@w3.org
Azzurra Pantella wrote: > > I think you are right! > It can't really be called a bug but a sort af unexpected and undesired > behaviour, not to say a programming error. > In fact which reason might there be not to recover after a write which > resulted in a broken pipe? > I consider the side effect of loosing requests quite serious. > But let me ask you something: > -Have you too observed some requests loss? What you call "requests loss" is: - normal behavior of tcp communication (any host can close the connection at any time) or - memory issues in the program > -When you talk of timers, do you mean the HTTimer object bound to the output > stream defined in HTBufWrt.c? > If this is the case, why ,in your opinion, checking out the value of > this timer in the HTBufferWriter_lazyFlush()? > Why not cheking and eventually dispatching its cbf function only in the > HTEventListLoop (HTEvtLst.c) as we do for > any other timers? Recovery would be quite easy and hopefully safe. Indeed it look a little strange. But many things was looking strange 'til I understand it. It really took me long to understand just little parts of the lib. However I'ven't got issue with this timer. Are you doing only 'GET' request or also 'POST'? > -Are you too having memory growth when submitting many requests to the same > host ? > If so you may refer to other mails with subject "HTAnchor" in the mailing > list . In fact there are no more doubt that the HTAnchor objects are never > canceled until the end of the program execution and that a new HTAnchor > object is created for every new request to the same host if the urls are > different. > I've tried to wrote an equivalent version of HTAnchor_delete. It's not full tested but it' far better than those crashing li3w one! I miss time to test it more. Michel.
Received on Tuesday, 18 December 2001 00:27:05 UTC