[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