[cap-talk] Socket transfer between Windows processes

David-Sarah Hopwood david-sarah at jacaranda.org
Wed Nov 25 18:35:50 PST 2009

David-Sarah Hopwood wrote:
> DuplicateHandle doesn't work on sockets, but something sufficiently like
> local sockets could be implemented in terms of pipes (either named or
> anonymous), and then the connected pipe endpoint handles would be
> transferrable.
> Mark Seaborn wrote:
>> In NaCl, the filename string is replaced with a pair of descriptors,
>> created by the system call imc_makeboundsock(), of types SocketAddress
>> and BoundSocket.
> [...]
>> In NaCl, the primary means of sharing is to share SocketAddress
>> descriptors, because ConnectedSockets are not transferrable.
>> The reason ConnectedSockets are not transferable is that the current
>> implementation of descriptor-passing on Windows requires that the
>> recipient process does not change during an imc_sendmsg() operation.
> Makes sense, if they implement NaCl sockets as Windows sockets. If they
> reimplemented them as pipes, then I think it could be made to work. But
> pipes are sufficiently different to sockets that this would likely involve
> a lot of rework (to the implementation of NaCl sockets, not necessarily
> its interface).

OK, so they *do* already implement them as pipes and transfer the endpoints
using DuplicateHandle:


(Should have checked that before my previous post.)

Mark Seaborn wrote:
> NaCl has to ensure that there can only be one recipient process,
> otherwise there could be a race condition:  the Windows handle could
> get transferred to one process, while the handle ID is received by a
> different process.

Yep. Any use of process IDs is potentially racy. However, according
to the comment at the end of
if you have an open handle to a process, then:

# The process handle lifetime is independent of the process lifetime.
# Until you CloseHandle the process object will continue to exist and
# be useable and its process ID will not be reused.

David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20091126/c2ef10a8/attachment.bin 

More information about the cap-talk mailing list