Yes its me again =)
For those who remember me, new drivers are almost compelte.
This little bug is bothering me, even though I could leave it alone and its unlikely that it would ever bring things down, I’m just curious:
I create a shared memory object using shm_open in a driver process. Client processes then also shm_open into this shared memory and it is used as a mass data transfer buffer. Now, multiple client processes should, in theory, be able to open and close this file descriptor, however it seems that whenever a client processes attempts to close its file descriptor (through shm_unlink() or through standard close()) , the shared memory object is removed from the directory path and all other open attempts fail.
Now it seems to me that for every open call there should be a close call. If a cilent opens the shared memory descriptor, there should be some way for that client to call a close without destroying the object entirely, otherwise a bunch of dangling open file descriptors could pile up.
The shm_unlink documentation states that calling it will remove the file path entry for the object, but not destroy it until other all other connections using the object close out. (Though no new connections are allowed). A simple close(fd) call seems to just destroy the object outright.
Is it considered correct to just open a shared descriptor and not call some sort of close when finished with it? I’ll be the first to admit I’m not terribly familiar with the theory behind this stuff. If its not, then what call is correct?
(Back I go to see if i’m just making some stupid msitake)