Hi Corinna, On Mon, 28 Feb 2022, Corinna Vinschen wrote:
> On Feb 28 10:24, Corinna Vinschen wrote: > > On Feb 25 16:46, Johannes Schindelin wrote: > > > On Tue, 22 Feb 2022, Corinna Vinschen wrote: > > > > On Feb 21 14:36, Johannes Schindelin wrote: > > > > > If there is appetite for it, I wonder whether we should do something > > > > > similar > > > > > for `/dev/shm` and `/dev/mqueue`? Are these even still used in Cygwin? > > > > > > > > "still used"? These are the dirs to store POSIX semaphors, message > > > > queues and shared mem objects. > > > > > > Okay. I guess we do not really use them in Git for Windows ;-) > > > > Probably not. I'm not aware that git uses POSIX IPC objects. > > > > > > These have to be real on-disk dirs. > > > > > > Could I ask you to help me understand why? Do they have to be writable? Or > > > do the things that are written into them have to be persisted between > > > Cygwin sessions? > > > > Cygwin uses ordinary on-disk files to emulate the objects, and > > they have to persist over process exits. Unfortunately I don't > > see any other way to create persistent objects from user space. > > Btw., you don't have to create those dirs. Only if you actually use > POSIX IPC calls, the directories are required. > > In fact, the IPC objects are just mmaps (message queues, shared mem > objects), or the file is just used to store the values after closing > the object (semaphores). Okay, I _think_ I understand the issue better now. Thank you for indulging me! > With "persistent" I mean, "DLL lifetime persistent". It's not required > that the objects are persistent until system shutdown, as it is now with > file-based objects. > > It would be sufficient if the objects persist until the last Cygwin > process of a Cygwin process tree exits. I'm open to ideas, but they > shouldn't further slow down the startup of a Cygwin process tree. From my limited understanding, that _sounds_ as if a shared object might be enough (similar to the shared parent directory that `winsup/cygwin/shared.cc` is all about). If this sounds like a viable approach, I'll put it into my ever-growing backlog ;-) Ciao, Johannes
