thanks for the info Ronnie. Seems as though apache is buffering, as my results are still being truncated. time to start thinking up another idea i suppose.
-----Original Message----- From: Ronnie Brunner [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 08, 2006 1:35 PM To: David McTavish Cc: [email protected] Subject: Re: flush or blocking web::put Hi David > I was wondering if anybody had any information on how to block on > calls of web::put until the client receives all of the content, OR, > conversely to flush the socket, OR, to detect if all web::put's have > been received by the client over the socket. I don't think you can find out if the client has all data (as there can be proxies around etc.) But what might help is trying to flush the output. As long as you don't use variables to write to (e.g. by [web::response -select #varname]) you should be able to flush the current default channel using flush [web::response] This flushes the Tcl channel to Apache (in your case) or Stdout in CGI and shell mode. > I'm having problems with websh & my application using large amounts of > memory which are never reclaimed by apache, so in an effort to reduce > the overhead of the process, I'd like to kill the socket. I initially > attempted to do this by using the retire method of the websh > interpreter, however, that does not seem to reclaim any memory > whatsoever (running apache 1.3 on freebsd 5). The code in web::finalizer is only called when the interpreter is retired anyway (just before Tcl_DeleteInterp() is called) -> Your attempt to retire the interp does not help. As for the memory: Tcl has its own memory allocation/freeing mechanism. If I'm not mistaken, Tcl allocates memory in chunks and uses this for multiple internal "allocs". When freeing it also just keeps track of what's used and whatnot -> even if you delete objects and variables and whatever, it does not mean that there is actually any memory freed (I think). Imho this has nothing to do with Websh but with Tcl. (That helps doesn't it ;-) > since this wasn't doing anything, i decided to just kill the child > process and force a new one to start, ie: ... > however, this has the awkward behaviour of truncating hte html > received by the client. i dont want to add sleeps into the code for > various amounts of time, as this code is in place at sites with large > amounts of latency, so determining the amount of time to sleep is > difficult at best. is there a way to determine whether the current > websh socket is flushed of data? As mentioned above: try flush [web::response] but no guarantee. Apache might as well just buffer the output and still truncate it if the process dies... hth Ronnie -- Ronnie Brunner | [EMAIL PROTECTED] phone +41 (0)44 247 79 79 | fax +41 (0)44 247 70 75 Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
