From owner-freebsd-hackers Fri Sep 20 6:10:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F25137B40C for ; Fri, 20 Sep 2002 06:10:18 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EF4B43E3B for ; Fri, 20 Sep 2002 06:10:17 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226]) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g8KDA6k28541; Fri, 20 Sep 2002 16:10:07 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.12.5/8.12.5) with ESMTP id g8KDA12n016530; Fri, 20 Sep 2002 16:10:01 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3D8B1E91.B95DFC6E@FreeBSD.org> Date: Fri, 20 Sep 2002 16:11:45 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Andriy Gapon Cc: eischen@pcnet1.pcnet.com, julian@elischer.org, hackers@FreeBSD.org Subject: Re: libc_r in stable References: <20020915231311.J53171-100000@edge.foundation.invalid> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Andriy, First of all thank you for your detailed reports, they could be very useful. Unfortunately, currently I am a bit busy due to participation in first Ukrainian OSS Conference, therefore it might be better to submit those reports to someone else - I'd recommend either Daniel Eischen or Julian Elischer (both CC'ed), who are FreeBSD libc_r gurys, and see if they could help you. Thanks! -Maixim Andriy Gapon wrote: > > Maxim, > > sorry if my English is not perfect, but I've decided to use it as more > offcial language of FreeBSD. > > I have recently been involved into debugging a complex program on FreeBSD > 4.6.2 (multiprocessed, multithreaded, signal handling, pipes and fifos for > communication) and based on that I've developed several concerns and ideas > about pthreads in 4.6.2. I'll start with the most obvious and proceed to > the ones that I'm not quite sure about. > > 1. write() doesn't set errno to EINTR if thread receives a signal while > being on a queue waiting for a data on a descriptor > > 2. in the case above, write() always returns -1 regardless of wheather it > was able to write part of data on previous attempts, I believe it should > return number of bytes written thus far > > 3. likewise, in the case "real" write() system call returns value < 0, > libc_r write() retruns the same value, although some data might have been > written on the previous attempts. > > 4. libc_r execve() sets all descriptors that were not set expicitely to > non-blocking mode to blocking mode before doing "real" execve, which is > good and done with non-multithreaded programs possibly being exec'ed in > mind. However, it has a painful effect if this is done as part of spawning > another process (fork+exec), obviously all descriptors in a parent become > blocking that effectively kills multithreading during IO. I think there is > no other option if a programmer really means to share descriptors between > a multithreaded and a singlethreaded program. However, in the case > close-on-exec flag is set on the descriptor, I think, it's better to leave > the descriptor as is, in the non-blocking mode. > > 5. I see that on SIGCHLD received descriptors are reset back to the > non-blocking mode with a comment that this is to undo possible setting > them to blocking state by a child. There is a number of concerns about > that: > a. what if not all of the singlethreaded child processes that > share descriptors with a multithreaded parent exited ? > b. SIGCHLD may be generated when a child process stops e.g. by ^Z > on a controlling terminal, when it continues the shared descriptors > will remain in the non-bloking state. > c. descriptor flags are reset to union of a saved explicitely set > value and O_NONBLOCK block flag. This may erase changes performed > by fcntl() in a child process, which in some exotic case may have > been ment to persist after the child exits. > > Frankly, I have no good ideas about 5, and obviously all problems with 4 > and 5 are there only if one mixes programs linked with libc and libc_r > into parent-child relationships and obviously there seems to be no perfect > solution for such situation, but maybe some improvements can still be > made. > > -- > Andriy Gapon > * > Hang on tightly, let go lightly. Andriy Gapon wrote: > > Maxim, > > in addition to my previous report: > > 6. open() from libc_r should add O_NONBLOCK to flags before executing > open() system call, but after saving actual flags value. > Otherwise, in the situations where system open() > blocks a whole calling process is blocked, where only a calling thread > should actually be blocked. Necessary retries (similiar to read() and > write()) should obviuosly be added too. Andriy Gapon wrote: > > ---------- Forwarded message ---------- > Date: Tue, 17 Sep 2002 13:29:08 -0400 (EDT) > From: Andriy Gapon > To: Maxim Sobolev > Subject: libc_r in stable (fwd) > > Maxim, > > in addition to my previous report: > > 6. open() from libc_r should add O_NONBLOCK to flags before executing > open() system call, but after saving actual flags value. > Otherwise, in the situations where system open() > blocks a whole calling process is blocked, where only a calling thread > should actually be blocked. Necessary retries (similiar to read() and > write()) should obviuosly be added too. > > ---------- End of forwarded message ---------- > > sorry about this one, didn't think it through. Looks like, although > current behaviour is not good enough, it is the only thing that can be > implemented non-intrusively, by userland means only. It's impossible to > properly emulate blocking open() via non-blocking open() for all possible > scenariosn alltogether: regular files, fifos/pipes, devices. > > -- > Andriy Gapon > * > Hang on tightly, let go lightly. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message