- From: <jose.kahan@w3.org>
- Date: Fri, 28 Jul 2000 10:42:19 +0200 (MET DST)
- To: "Kallweit, Heiner" <Heiner.Kallweit@commerzbank.com>
- CC: www-lib@w3.org
Hello Heiner, Good work. I have just some final doubts before making the commit. In HTHost_forceFlush() you return HT_ERROR if the in_flush flag is set. The only place where this may make a problem is in HTTP.c:1192, where the return code is used to select the next HTTP automata state. I'm not sure if we should return HT_ERROR or HT_OK or something else then if we catch the flag. I looked again at your previous mail, where you give the following stack: >requests via Libwww and SSL. Every 100th request I got a core dump. >Eventually I found out that there is a recursive function call. To cut a >long >story short: HTHost_forceFlush -> HTTPEvent_Flush -> >HTBufferWriter_lazyFlush >-> HTSSLWriter_write -> HTSSLReader_read -> HTHost_forceFlush Do you remember where was the first HTHost_forceFlush called? That is, could you give the whole stack up to that call? It may be that your solution is good, but that it could be better to set the in_flush flag in the function that will make the HTHost_forceFlush call (I'm thinking about the SSL glue code). It may also be that there's an extra HTHost_forceFlush call that shouldn't be called or that the problem is elsewhere? I'll try to see if I can find something here too. If we don't make much progress, I guess I'll propose your patch as an experimental one and differ its integration into the main code. Just because I'm not sure about the side effects. -Jose
Received on Friday, 28 July 2000 04:42:32 UTC