Libuv: Sockets, Pipes and File handles

[Stephen von Takach]

Hi all,

We have an issue where passing a socket over a pipe leads to a duplication of file handles (same handle) to the one socket. Once the socket closes, the process / thread that was passed the socket sees the socket close, however libuv holds a reference to the socket which remains in CLOSE_WAIT status

Please have a read of https://github.com/cotag/spider-gazelle/issues/20 for more detailed information.

Closing the socket on the sender thread seems like a bad idea, how should this be handled?

[Saúl Ibarra Corretgé]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think you are hitting the handle IPC on Windows problem. Basically,
IIRC, it's not working as of right now. Sending handles over pipes
works across processes, but not across threads ATM.


Cheers,

- --
Saúl Ibarra Corretgé
bettercallsaghul.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJTpUp8AAoJEEEOVVOum8BZzTgP/jet0NgaInIzJaywkm/e5fC1
YBUIxWNHEgAkPKrW0nq0SSqkDT7G2Cz/lO3MKmqEQMQOpuGsN3fhWML4mEB2uq1b
tD7mkb+zXbTE27AwswCzmwS9EqR0k9LaaqhM5/TwGVXn2+wwnQpiINdqv67Rnzg+
/N0Ql/l0QdBb9u7qUoi5id/fUQIRlBR9ekrWTEqTh40AMZWDyY8oZeTUrdzcSiza
q4bRMsN2VxgSIewiTJf07D+USnuG2CPsw6Tw5zhvqw/0kSgB3m7aZ9FqZnMzU5Q7
4ODLJt8D7ByuotFbvauMpL7mIiO9jThlPk/w+ZbvZbvCfcMguJd9xUC0aTzsRdKs
ygOcMV/8f3dMs7FVI6huk40Q9PZAlxXidxJLm+bSxFC4Xqy+GrnNNesSDoHfcNTD
uEFteaUWW/fpl075zy55edXjYSRa8BJWN3y7gy8NUzM45cS5U/R4vB8ZWXvsRicZ
Sp/RXf/y0jpC6uh7vJvPWrNTx/r842Zskw0n1uSt39Kqk/rCy9hBu9FSDaY4hsD+
XoG8QiAGQ5Y+w80KErt5Ujbq8W7LwADlVEEKwzUWdbSleh92Xb9WOuybqVZiGaHp
VLZGDYyTpWLra7ghCvDLzKNy13RSUpl/zD5wSfmjTICYtV2gt9Tx2qTYp7kQDr3t
qeP+JYsIZ2G7gslyMuVp
=YQPo
-----END PGP SIGNATURE-----

[Stephen von Takach]

Actually I run on Windows no problem as we don't use pipes (windows is single threaded). If you have a look at the spider gazelle issue this is the behaviour we are experiencing on Linux

--
You received this message because you are subscribed to a topic in the Google Groups "libuv" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/libuv/9-ocoaxmYKw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to libuv+un...@googlegroups.com.
To post to this group, send email to li...@googlegroups.com.
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

--
Regards,

Stephen A. von Takach | Technical Lead

ADVANCED CONTROL & ACOUSTICS
Lot 2, Pier 8/9, 23 Hickson Rd  | Walsh Bay | NSW | 2000              
M +61 408 419 954  |  E st...@advancedcontrol.com.au

W http://www.advancedcontrol.com.au/

[Saúl Ibarra Corretgé]

Do you have a self-contained test case I can try to reproduce?

You received this message because you are subscribed to the Google Groups "libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libuv+un...@googlegroups.com.

[Stephen von Takach]

Not beyond the server implementation. I am more interested in understanding desired behaviour and if we needed to close the libuv socket reference on the sender thread after sending it over the pipe.

To unsubscribe from this group and all its topics, send an email to libuv+unsubscribe@googlegroups.com.

To post to this group, send email to li...@googlegroups.com.
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

[Stephen von Takach]

Awesome seems once the socket has been sent to the new reactor, it must be closed on the origin reactor - this doesn't effect the connection, which remains open on the receiving reactor.

Leak resolved :)

On Sunday, 22 June 2014 01:32:25 UTC+10, Saúl Ibarra Corretgé wrote:

To unsubscribe from this group and all its topics, send an email to libuv+unsubscribe@googlegroups.com.

To post to this group, send email to li...@googlegroups.com.
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.