Re: CVS commit: src

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Hi,

yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi) wrote:
> > Log Message:
> > Add shm_open(3) and shm_unlink(3) to support POSIX shared memory
> > objects. They are implemented using tmpfs (mounted at /var/shm).
> > 
> > Discussed on tech-{kern,userlevel} (quite a while ago).
> 
> thanks for working on this.
> 
> does this (and the relevant sysinst commit) mean that we provide
> a different set of functionality depending on the amount of memory?
> i don't think it's a good idea.  poor performance on poor system
> is ok.  but the lack of functionality is confusing.
> IMO the fstype check should be removed.  (and probably make cleartmp
> clean /var/shm as well.)

If /var/shm is not in tmpfs we return ENOTSUP.  My concern is that the
users of this API might have certain expectations about the *speed* of
this memory storage.  Think about synchronisation mechanisms implemented
using POSIX shared memory.  If the underlying implementation may trigger
disk I/O, the latencies may hit the roof and thus have very significant
impact on the application using such interface.  For this reason, I would
even prefer adding wired-only (-w or whatever) mount option for tmpfs and
use it for POSIX shared memory.  Yes, mlock(2) is still available, but we
are talking about the defaults and the expectations.  If the user does not
have expectations about the speed, then why would it use this API instead
of just mmap()ing a file?

Hence, I leaned towards not supporting the interface, instead of providing
one which does not meet the expectations.  What do you think?

> YAMAMOTO Takashi
> 

-- 
Mindaugas