`multiprocessing.shared_memory.SharedMemory` currently tries to unlink a POSIXshared memory object if it fails to `mmap` it after opening/creating it.However, since it only catches `OSError`, it fails to do so when opening anexisting zero-length shared memory object, as `mmap.mmap` raises a `ValueError`when given a 0 size.Fix this by catching all exceptions with a bare `except`, so the cleanup is runfor all errors.

… handling`multiprocessing.shared_memory.SharedMemory` currently tries to unlink a POSIXshared memory object if it fails to mmap it after opening/creating it in theconstructor. It does this by calling `cleanup()`, which unregisters the sharedmemory despite it not having been registered. This will trigger a separateexception in the resource tracker.Fix this by calling the low-level unlink directly.

`multiprocessing.shared_memory.SharedMemory` currently attempts to `unlink` aPOSIX shared memory object it has opened or created if a subsequent exceptionis raised in its constructor.This is necessary to avoid it leaking if the shared memory object was createdin the constructor, however it seems inappropriate if it is opening apre-existing shared memory object.Fix this by only unlinking the shared memory object if it was created.

These are allowed by POSIX and it seems more consistent/cleaner to support themthan forcing the user to treat them as a special case.Windows does not support creating a zero-length mapping, and neither does`mmap` on any platform, so skip those operations and assign a zero-lengthbuffer instead.TODO: The way the POSIX/Windows code is interleaved inside if statements makesfor difficult to follow and deeply nested logic. It might be better to refactorthis code and keep the platform-specific logic in separate functions orpossibly even implementation classes.

It appears MacOS has tight limits on name length which the new tests wereexceeding.