elast0ny / shared_memory

A Rust wrapper around native shared memory for Linux and Windows
382 stars 51 forks source link

adding a simple backoff mechanism for macos #72

Closed p-avital closed 3 years ago

p-avital commented 3 years ago

As far as I was able to test, fixes #71 The backoff is currently only for macos. Since the error was already a bit hard to trigger, I think yielding 10 times should be enough.

elast0ny commented 3 years ago

I beleive the PR does not directly address the race condition :

  1. The race condition happens because shared_memory has this feature where you can use "file system" based files (I called them flinks) to open your shared memory mappings. This is achieved by creating a file on disk that contains the unique ID for the shared memory mapping that you would normally use to open the shared memory. So when you are the owner of the shared memory and creating this flink on disk, you first create the file on disk and then you write the unique ID of the shared memory mapping so that other processes can get the unique ID. The race happens when another process sees that the flink exists on disk and then tries to read the unique ID but the creator of the flink has no yet written the unique ID to the file (or maybe it is partially written). In your changes here, the retry attempts will keep retrying to open the shared memory with an invalid unique ID as it doesn't try to re-read the ID from the flink.
  2. This retry mechanism only needs to happen if a flink_path is provided/used as the race condition is only related to the time between the creation of the flink and writing the unique ID to the flink.

Feel free to address these issues or I also don't mind modifying the PR later today when i will have more spare time

p-avital commented 3 years ago

I think my understanding of the race condition was a bit too limited for that, sorry.

It might be wiser for you to do it, especially if you already have an idea of how :)

elast0ny commented 3 years ago

Fixed as part of #74