[issue37754] Consistency of Unix's shared_memory implementation with windows

2019-09-11 Thread Davin Potts
Davin Potts added the comment: I have created issue38119 to track a fix to the inappropriate use of resource tracker with shared memory segments, but this does not replace or supersede what is discussed here. -- ___ Python tracker

[issue37754] Consistency of Unix's shared_memory implementation with windows

2019-09-09 Thread Vinay Sharma
Vinay Sharma added the comment: Hi @davin, I researched on lots of approaches to solve this problem, and I have listed down some of the best ones. 1. As Eryk Sun suggested initially to use advisory locking to implement a reference count type of mechanism. I implemented this in the current

[issue37754] Consistency of Unix's shared_memory implementation with windows

2019-09-09 Thread Davin Potts
Davin Potts added the comment: A shared semaphore approach for the resource tracker sounds appealing as a way to make the behavior on Windows and posix systems more consistent. However this might get implemented, we should not artificially prevent users from having some option to persist

[issue37754] Consistency of Unix's shared_memory implementation with windows

2019-08-26 Thread Vinay Sharma
Vinay Sharma added the comment: Since, advisory locking doesn't work on integer file descriptors which are returned by shm_open on macos, I was thinking of an alternative way of fixing this. I was thinking of using a shared semaphore, which will store the reference count of the processes

[issue37754] Consistency of Unix's shared_memory implementation with windows

2019-08-24 Thread Vinay Sharma
Vinay Sharma added the comment: Also, shm_open returns an integer file descriptor. And when this file descriptor is passed too fcntl.flock (in macOS) it throws the following error: OSError: [Errno 45] Operation not supported Whereas, the same code works fine on linux. Therefore, I have

[issue37754] Consistency of Unix's shared_memory implementation with windows

2019-08-24 Thread Vinay Sharma
Vinay Sharma added the comment: Hi, I just opened a PR implementing a fix very similar to your suggestions. I am using advisory locking using fcntl.flock. And I am locking on file descriptors. If you see my PR, in resource tracker I am opening a file "/dev/shm/", and trying to acquire