Ability to set custom name for the server

[bobi6666]

There should be a method, when spawning an IPC server, that lets you pass in your own name. There should be another method that checks if a given name is already used, which I believe your one-shot function uses internally to generate random names until it comes up with one that's free. We have run into a use case where it would be much more preferable to have the server process passed the name of the pipe to use on its command line, rather than have to somehow communicate back to the client what its name should be before actual IPC is established.

[glyn]

It seems that the name generation is a little more involved than the OP describes and depends on the OS and whether the "force-inprocess" feature is enabled:

• macOS constructs and registers a global "bootstrap" name, both using Mach ports
• Windows constructs a pipe ID from a UUID and then creates a named pipe using the pipe ID
• unix creates a UNIX socket and uses the socket path as a name
• "in process" constructs a name from a UUID and stores that in a static hashmap.

So it would seem to be straightforward to set a custom name for Windows and "in process", but possibly more involved for macOS and unix.

Maintainers: what's your policy for implementing features that are not specifically required by Servo? Is this generally acceptable or do you only allow this when there isn't significant impact to the design? I'm trying to gauge whether this feature is likely to be acceptable if someone implemented it. /cc @antrik @pcwalton @jdm @nox @mrobinson

[jdm]

I'm ok with features that Servo doesn't use. There are some if those in the library already.

[glyn]

Thanks @jdm! I'm mulling over some implementation options:

1. Support custom server names in the platform layer using a new static hashmap for each OS and leveraging the existing static hashmap for "inprocess" (i.e. four independent implementations), with a thin wrapper in ipc.rs.
2. A variation of option 1 using common code (including the new static hashmap) in the platform layer for the three OS's (but still with an independent implementation for "inprocess").
3. Support custom server names in ipc.rs using a new static hashmap and building on existing one shot server support in the platform layer.

Option 3 is the most maintainable, but results in two static hashmaps in the "inprocess" case, which could impact performance a little. Option 2 is a bit less maintainable than option 3, but reuses the existing static hashmap in the "in process" case, so would perform a little better in that case than option 3. Option 1 is possibly the least maintainable as it would duplicate code for each OS. The performance of options 1 and 2 is similar, but option 2 introduces common code into the platform layer, which I think deviates from the current design of having independent implementations for each OS and "inprocess".

Do you have a feel for which option(s) is likely to be most acceptable? I'm not sure whether we are aiming for ultimate performance or maintainable code. Also, I'm not sure how wedded the project is to having four independent implementations in the platform layer or whether it might be ok to evolve towards sharing some common code. Or is it preferable to push common code up into ipc.rs?

FWIW I would recommend trying option 3 first and switching to option 2 or 1 if the performance turned out to be unacceptable (which I suspect is unlikely).

(Option 1 might also permit more sophisticated implementations for certain OS's. For example, it may be possible to use named OS primitives for one shot servers with internally generated names and to use other OS primitives for one shot servers with custom names. I am currently ruling out more sophisticated implementations because of the extra complexity.)