File::lock is documented as

This acquires an exclusive lock. No other file handle to this file, in this or any other process, may acquire another lock. If this file handle/descriptor, or a clone of it, already holds a lock, the exact behavior is unspecified and platform dependent, including the possibility that it will deadlock. However, if this method returns, then an exclusive lock is held.

This seems to say fairly clearly that the lock is scoped to the handle.

However, on Solaris, this is implemented with fcntl(fd, F_SETLK). The regular POSIX behavior for this lock is that it is process-scoped, and the docs I was able to find for Solaris seem to confirm that:

When a shared lock is set on a segment of a file, other processes will be able to set shared locks on that segment or a portion of it. A shared lock prevents any other process from setting an exclusive lock on any portion of the protected area. A request for a shared lock will fail if the file descriptor was not opened with read access.

(emphasis mine)

So... shouldn't we just return "lock() not supported" on Solaris, like we do for other Unixes that don't have flock?

This was implemented in #146269.
Cc @the8472 @weihanglo @Mark-Simulacrum @psumbera @kulikjak