Date: Wed, 23 Apr 1997 09:50:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: fenyo@email.enst.fr (Alex Fenyo (eowyn)) Cc: terry@lambert.org, freebsd-hackers@FreeBSD.org, jb@cimlogic.com.au Subject: Re: fd locking problem with libc_r ? Message-ID: <199704231650.JAA29076@phaeton.artisoft.com> In-Reply-To: <d0667xetuik.fsf@nikopol.enst.fr> from "Alex Fenyo (eowyn)" at Apr 23, 97 03:09:23 am
next in thread | previous in thread | raw e-mail | index | archive | help
> .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...). I really don't know if this is intentional, to ensure order of operation, or if it's just a side effect of the implementation. The operations map would have to be kept seperately for this to work; it's not impossible, and it's probably not correct the way things are, but it's not currently done. The threads stuff is originally out of MIT; they would either be interested in patches, or able to tell you why it must stay the way it is. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704231650.JAA29076>