Date: Thu, 11 Feb 1999 02:29:33 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter.jeremy@auss2.alcatel.com.au (Peter Jeremy) Cc: dillon@apollo.backplane.com, tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC Message-ID: <199902110229.TAA09779@usr06.primenet.com> In-Reply-To: <99Feb11.122748est.40371@border.alcanet.com.au> from "Peter Jeremy" at Feb 11, 99 12:38:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >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. > > Could someone please describe what the problem(s) are and what impact > they have on applications using SysV semaphores. > > I have an application (running on 3.0-RELEASE) that relies on the > kernel correctly tracking SEM_UNDO's. (Basically I have a wrapper > that seizes a semaphore with sem_op = -1, sem_flg = SEM_UNDO and then > execs a process that knows nothing about the semaphores.) I was > seeing some wierd behaviour, but I thought that was a (now fixed) bug > in the kernel handling of SEMUME and SEMUSZ (see PR kern/9068). If the sem_op is a negative integer, and the absolute value of the sem_op is larger than the current value of the semaphore, and the value of (sem_flg&IPC_NOWAIT) is false, then the operation is ignored. The operation is *supposed* to increment the sem_cnt, and suspend the calling process. Apparently, this isn't done because of the need to tie it into the signal code (see the tsleep at ~ line 758 of kern/sysv_sem.c). Oh yeah; while I'm at having to prove someone else's bug report is a valid bug report, it's supposed to return EIDRM instead of EINVAL; contrary to the comments at ~ line 770, BSD *does* define this value. I'm pretty sure no one has bug reported that, though... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199902110229.TAA09779>