Date: Tue, 9 Feb 1999 15:10:52 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Terry Lambert <tlambert@primenet.com> Cc: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies), hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC Message-ID: <199902092310.PAA61722@apollo.backplane.com> References: <199902092246.PAA10658@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:FreeBSD does not select writeable on sockets. Sockets can be
: written if there are mbuf's available, and mbuf's can
: become unavailable asynchronously between the select
: coming true and the subsequent write. Select for
: write is generally an artifact of porting a winsock
: program to a UNIX system.
Huh? Sure it does. The availability of mbufs in the memory pool
has little to do with select()ing a socket for write. mbuf exhaustion
is a rather serious error.
:> mmap - stable? limitations?
:
:FreeBSD has a unified vm and buffer cache. In theory, you do not
: need to call msync(2), ever, on such a system. However,
: there are a number of coherency bugs that make it necessary
: to call it (mostly in INN-type situations, where the file is
: being extended while it is mapped).
What coherency bugs? As far as I know, extending a mmap()'d file
works just fine. You cannot *write* into the mmap()'d area beyond
the end of a file until you ftruncate() the file larger, but that is
true on all implementations that I know of. It is also appropriate -
the validity of the mmap()'d data only extends to the logical end of
file.
:The overall size of the shared memory segment is limited to that
: which can fit in the kernels virtual address space; this
: artificially restricts the maximum size.
:FreeBSD semaphores are inadequately resource tracked in _exit().
All semaphores are inadequately resource tracked in _exit(), it's a
problem inherited from the SYSV implementation.
: Terry Lambert
: terry@lambert.org
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902092310.PAA61722>