I don't think the "fix" is right. Also, I don't think things are happening
the way you describe. I could be wrong. In the fcopy docs, when they
say the "socket is closed", they mean that, for example, "TclHttpd closes
the socket", which is not happening here. Instead, the remote peer is
closing its socket. In that case, the worst that can happen is that
the write by fcopy will get an I/O error. In that case, the -command
callback is still invoked.
To debug leaks, create a .tml page that embeds the "File_List" command.
I don't think there is one in the sample htdocs area, but you can easily
create "file.tml" that simply contains
[File_List]
and it will create a report of the open file descriptors. For sockets it
reports the remote address. For files it records the name of the file,
as long as the "opentrace" hack is in place, which I think is on by default.
>>>Jeff McWhirter said:
> In tclhttpd3.1 I encountered a problem of "leaking" sockets.
>
> In Httpd_ReturnFile there is a call to Httpd_Suspend:
> Httpd_Suspend $sock 0
> that removes any fileevent listeners on the socket and any cleanup timer eve
nt
> handlers.
>
> The Httpd_ReturnFile then does a fcopy:
> fcopy $in $sock -command [list HttpdCopyDone $in $sock $close ]
>
> The problem arises if the browser breaks the connection during the fcopy.
> (Try many reloads of a page from a localhost server using IE).
> fcopy does not call the callback when this happens and the Http socket data
never
>
> gets cleaned up. (I am not sure if the socket itself gets closed or not -
I
> suspect
> it doesn't due to some browser errors about tcp memory I am getting).
>
> >From the fcopy docs:
> >You are not allowed to do other I/O operations with inchan or outchan durin
g a
> background fcopy.
> >If either inchan or outchan get closed while the copy is in progress, the
> current copy is stopped and
> >the command callback is not made. If inchan is closed, then all data alread
y
> queued for outchan is
> ^^^^^^^^^^^^^^^^^^^^^^^
> >written out.
>
> A fix is to add an event listener on the socket after the suspend :
> Httpd_Suspend $sock 0
> fileevent $sock readable [list Httpd_CopyFailed $sock]
> fcopy $in $sock -command [list HttpdCopyDone $in $sock $close ]
>
> which closes the socket:
> proc Httpd_CopyFailed {sock} {
> fileevent $sock readable {}
> Httpd_SockClose $sock 1 ""
> }
>
> Of course from the fcopy docs
>
> >Note that inchan can become readable during a background copy. You should t
urn
> off any fileevent
> >handlers during a background copy so those handlers do not interfere with t
he
> copy. Any I/O
> >attempted by a fileevent handler will get a "channel busy" error.
>
> Though of course we aren't doing IO - just closing the socket.
>
>
> Brent - is this a correct fix?
>
> -Jeff McWhirter
>
>
>
>
-- Brent Welch <[EMAIL PROTECTED]>
http://www.ajubasolutions.com
Scriptics changes to Ajuba Solutions
scriptics.com => ajubasolutions.com
