Re: CVS commit: src

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

> 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?

because the api is easier to use?

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

does returning ENOTSUP improve the situation?
it merely make the most applications abort or crash, i guess.

YAMAMOTO Takashi

> 
>> YAMAMOTO Takashi
>> 
> 
> -- 
> Mindaugas