At Mon, 23 May 2011 12:52:12 +0100, Tim Brown wrote: > My never ending battle to get racket to play nice with Solaris continues: > [...] > STREAMS and STREAM fds on Solaris use fcntl(F_GETLK/F_SETLK, F_SETLKW) > and their 64-bit counterparts F_GETLK64 etc. However, these need a pointer > to a lock structure to be managed/associated with the fd, and I'm not sure > what the best means to do this would be (there seems to be a neat solution > to a lot of the things in racket -- best left to the authors IMHO).
I don't think the OS holds onto the struct provided with F_SETLK (because that's not the sort of thing that a Unix would do); it copies the information out. But... > Solaris seems to take quite a dim view of flock(); from man flock(): > > NOTES > > Use of these interfaces should be restricted to only appli- > > cations written on BSD platforms. Use of these interfaces > > with any of the system libraries or in multi-thread applica- > > tions is unsupported. > [...] > But is there any chance of a proper fcntl-based solution, then that would > be appreciated. That's nothing compared to the dim view of F_SETLK in the BSD world. The BSD-derived Mac OS X man page puts it this way: This interface follows the completely stupid semantics of System V and IEEE Std 1003.1-1988 (``POSIX.1'') that require that all locks associated with a file for a given process are removed when any file descriptor for that file is closed by that process. This semantic means that applica- tions must be aware of any files that a subroutine library may access. For example if an application for updating the password file locks the password file database while making the update, and then calls getpwname(3) to retrieve a record, the lock will be lost because getpwname(3) opens, reads, and closes the password database. The data- base close will release all locks that the process has associated with the database, even if the library routine never requested a lock on the database. >From a Racket implementor's perspective, the BSD side has it right. It's not just subroutines within Racket, but different threads within a single Racket process that might compete for a file lock; when a thread fails to obtain a lock and closes a file, any thread in the same OS process that held the lock immediately loses it. I don't see an easy way around the problem. Your patch to make file locks unsupported looks like the right one for now. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
