> btw: I don't know if passing HANDLE on Windows is supported (and I would > guess not).
Sure it is. DuplicateHandle() can be used for this. I.e. a process A that has the required access right (PROCESS_DUP_HANDLE) to two processes U and V can take a HANDLE value valid in source process U and duplicate it into a HANDLE value valid in the target process V. Then it just needs to pass that new HANDLE value (which is just a number, does not have to be kept secret or anything) using whatever normal inter-process messaging to process V and process V can use it. If I understand the documentation correctly, A must be either U or V, and in most cases presumably A == U, i.e. a process wants to give another process a duplicate of one of its own HANDLEs. Note that the duplicated handle is indeed just a number so no special mechanisms are needed to pass it to the target process. In process A, the duplicated HANDLE is not valid. It might have the same numeric value as some HANDLE (that refers to a totally unrelated object) in process A, but that is just a coincidence then. I hate to say this, but IMHO this a more obvious API than the fd passing over socket thing, which I have always found inelegant, non-obvious, and in a way quite non-Unixish. But then, ha, having said that, I now see this gem in the documentation: "You should not use DuplicateHandle to duplicate handles to the following objects: [,,,] Sockets. No error is returned, but the duplicate handle may not be recognized by Winsock at the target process. Also, using DuplicateHandle interferes with internal reference counting on the underlying object. To duplicate a socket handle, use the WSADuplicateSocket function." OK, so for sockets one needs to call WSADuplicateSocket() instead of DuplicateHandle(), and WSADuplicateSocket() takes just a target process parameter. Oh well, that corresponds to the most common case A == U anyway. (Windows named pipes also have functionality that I think could be used in a vague sense to achieve the same end means that fd passing is often used for, i.e. give another process access to something (an opened file) it wouldn't have access to (be able to open) otherwise. I am talking about the "impersonation" thing, but actually now that I think of it, this functionality is presumably usually used not to give the named pipe server access to something it wouldn't have access to otherwise, but on the contrary, to make a named pipe server restrict its rights to those of the client. And anyway, as Thiago has pointed out on the dbus list, named pipes are a pain to use.) --tml _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
