[erlang-questions] Can gen_tcp:close() close a socket which is still sending?

John Haugeland stonecypher@REDACTED
Sun Jun 14 19:31:05 CEST 2009


> After you issue a gen_tcp:close then if the server side is really slow and
> do not process any data for more than 5 seconds then the socket is closed any way.

It's lightning fast by design.  Having Erlang's excellent mature
timeslicer to work with has made it borderline trivial to make a
webserver that's fast enough to send Marty McFly back in time.

You heard me: my webserver goes 88 miles an hour.





> My guess is that you send some buffer that is queued in the operating system
> buffer and then you call close.

Well right now I'm just testing over localhost.  Same machine for
server and client.





> What happens then is up to the tcp implementation. Are you
> using Windows ?

This happens both under Vista Home Premium 64 and Gentoo 64.





> The "safe" way to terminate a sending socket is to use shutdown(S, write)
> and then wait for the server side to close the connection.

This here may be exactly what I need to know.  To check, first,
though: in context, erlang _is_ the server side.  Does that change
things?  The client is any web browser.  I apologize for having been
unclear.





> The shutdown interface will also wait until all data queued in the
> Port/socket is written to the
> operating system socket before issuing the low level shutdown.

See, that's what I would have expected.  Windows doesn't close sockets
with outbound data on them, when you're writing C/C++.  That right
there is a big part of why I'm worried I haven't yet correctly
diagnosed the problem.





> Hope this will lead you forward.

I suspect it has, but my being unclear about Erlang's role as a server
suggests I need to make sure I didn't actually present a wrong
situation for advice first.


More information about the erlang-questions mailing list