Date: Thu, 11 Feb 1999 16:07:25 +0800 From: Peter Wemm <peter@netplex.com.au> To: Terry Lambert <tlambert@primenet.com> Cc: kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC Message-ID: <199902110807.QAA61681@spinner.netplex.com.au> In-Reply-To: Your message of "Wed, 10 Feb 1999 16:30:05 GMT." <199902101630.JAA08698@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > However, as you point out, the fcntl() > > (and flock()) *locking* operations are not implemented. IMHO file locking > > on a socket is of pretty marginal value since there is no seek space > > (with the possible exception of using it for a mutex instead of using > > sendmsg() or something sensible). > > Yeah; the putative utility isn't really at issue, though, only whether > it works on Linux and not on FreeBSD. You could make the same argument > about value on SYSV IPC, since it's not select(2)'able. I wasn't talking about select(), I was talking about *file* locking on non-files like sockets and pipes. FWIW, it *looks* rather simple to implement this at a higher level since the kern_lockf.c code is not actually vnode specific at all. All that it (in theory) needs is for sockets and pipes to implement an advlock() op entry, fetch their per-pipe/ socket 'struct lockf *' and call lf_advlock(). lf_advlock() takes a VOP_* style argument but it doesn't need to, it could just as well take explicit args. My point is, if it was *useful* or *in use*, then somebody would have implemented it it. > > > FreeBSD fails to support fcntl's on pipes: F_SETOWN, F_GETOWN, F_GETLK, > > > F_SETLK, F_SETLKW. This is due to the use of struct fileops, > > > since pipes are not backed by true vnode objects. > > > > F_SETOWN/F_GETOWN are implemented as ioctl calls, that part is wrong. > > *Only* the file locking parts are not implemented since it's of such little > > value with no seek space. > > Hmmmm. From my reading of the sources, this is actually a fairly > recent addition (November 11th, 1998, by Truckman). I blame my > build environment for that particular lapse. I looked at the code and it isn't a new feature. What Don Lewis did was clean up the interfaces a little so that the functionality was tracked better to prevent SIGIO shootdowns. It's always been done this way (fcntl translated into an ioctl()), but it used to be done with TIOCSPGRP etc and now it's done with FIOSETOWN and friends. The functionality is a little more robust, it's not new. > I still don't think the non-existance of a real vs. a virtual seek > space is relevent. Supporting unused features causes bloat. Unless it's actually going to be useful and maybe even *used* then it's irrelevant. Incidently, I can see one use for it, and that's to do a mutex of some sort. Imagine a cooperative process pair that want to get records over a pipe or socket but the data is written non-atomically in multiple chunks, etc. This is a bad example though because there are better ways. > The obvious way to fix this is to hang the locks off the vnode, and > move the advisory locking out of all FS's (except the network clients, > of course, which may need to veto lock coelescence if the server > refuses the lock). This would fix nothing in these cases since sockets and pipes do not *have* a vnode. You've got me bugged now.. I had a quick shot at seeing just how hard it would actually be to implement locking for pipes and sockets. I was suprised at how easy it's turning out and (to my suprise) it slightly tidies a few things up a bit.. Cheers, -Peter -- Peter Wemm <peter@netplex.com.au> Netplex Consulting 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?199902110807.QAA61681>