Date: 23 Apr 1997 03:09:23 +0200 From: fenyo@email.enst.fr (Alex Fenyo (eowyn)) To: Terry Lambert <terry@lambert.org> Cc: freebsd-hackers@FreeBSD.org, jb@cimlogic.com.au Subject: Re: fd locking problem with libc_r ? Message-ID: <d0667xetuik.fsf@nikopol.enst.fr> In-Reply-To: Terry Lambert's message of Tue, 22 Apr 1997 16:54:37 -0700 (MST) References: <199704222354.QAA27858@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <terry@lambert.org> writes: > It's because only one blocking operation can be outstanding on an > FD at a time in a user space threading implementation. But then, I have two questions : .Why a select() waiting only to be able to write on a fd (select(nfds, NULL, writefds, NULL, NULL)), and a read on the same descriptor are allowed to be performed at the same time by libc_r ??? (such a select adds only a write lock on the descriptor) .Do you think the behaviour I talked about is posix compliant ? (my opinion is that it is not, because each time a thread blocks on read, nobody can write (on the same fd); difficult to handle !!!) I agree with you that only one blocking operation can be done at a time. But this is not a problem, because the two calls are not really done : they are done one time, in a non blocking way, then the two threads are discarded from the running queue, and then _thread_kern_sched() makes a big select (most of the time non blocking, if there is at least one thread in the running queue) with fdsets that contain all the descriptors that threads may wait on (by calls to select, read, write etc...). Sincerly, Alexandre Fenyo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d0667xetuik.fsf>