Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > > Yes, all resources specific to a process are deleted automatically, so, > > > any message queue descriptor or shared memory descriptor is > > > closed. Named objects are not deleted though, since they may be shared > > > between several processes, only non-pshared anonymous objects and named > > > objects *descriptors* are deleted. This is the only reasonable > > > implementation I could find. > > > > What about a usage counter maintained on creation/binding vs. > > closing/destruction? I would prefer to get them cleaned up automatically > > as well somehow, or we really need tool support for IPC cleanup, and > > that is ugly in my eyes. > > I am not sure one would expect a named object to be unlinked when one only > calls its "close" service, without calling its "unlink" service. If, on > the other hand, one calls the "unlink" service, then the object will be > automatically destroyed when the last descriptor is closed, as mandated > by the specification.
But if the creator of an object dies + there are no further open instances, I see no practical reason to keep this alive. I'm talking about the check on process exit here, not on explicit close(). > > Moreover, the existence of such objects is not a leak that will grow > over time, if one do not use the O_EXCL flag when opening objects, > existing objects will simply be reused. If one use the O_EXCL flag, > opening will fail. > > This behaviour is the same as Linux behaviour. > Well, I have sys-v ipc in mind where I used to fiddle a lot with ipcrm to get certain applications running again after unexpected termination. The reason was that the developers used the existence of certain ipc names to check if a central component was already running. Maybe it's really dependent on the actual ipc mechanism, and having the one characteristic for posix and some other later for native might be the way to go. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
