loki@NAZGUL.PHYSICS.MCGILL.CA (Loki Jorgenson Rm421) (04/09/91)
Is there any reason why I should not be able to use lockf() on /dev/audio? I haven't done extensive error-checking but the circumstances don't make it very easy. Basically, it is happens that one process may try to write to /dev/audio while another is reading (or vice versa). So I have tried to implement advisory locking in both processes with lockf(audio,F_LOCK,0); ... stuff ... lockf(audio,F_ULOCK,0); around any attempts to read/write/ioctl /dev/audio (Note: /dev/audio has been open()'d O_RDWR by both processes earlier). One of the side-effects of lockf(...,F_LOCK,...) is that it sleeps if there is already a lock on the file. This is desirable. What apparently happens is that at least one call to lockf() succeeds before both processes later fall asleep having failed to apply locks. It seems like the first F_ULOCK attempt fails after the first F_LOCK has been applied (both within the same process). However, this is conjecture. What I am really asking is if there is any reason why /dev/audio should be considered a special file (which lockf won't work on) and what alternatives are available if so? Thanks, __ __ Loki Jorgenson / / \ \ node: loki@Physics.McGill.CA Grad, Systems Manager / ////// \\\\\\ \ BITNET: PY29@MCGILLA Physics, McGill University \ \\\\\\ ////// / fax: (514) 398-8434 Montreal Quebec CANADA \_\ /_/ phone: (514) 398-7027