From owner-freebsd-hackers Tue Sep 24 8:58: 5 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 95B2437B401; Tue, 24 Sep 2002 08:58:01 -0700 (PDT) Received: from mta2.srv.hcvlny.cv.net (mta2.srv.hcvlny.cv.net [167.206.5.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BE1143E65; Tue, 24 Sep 2002 08:58:01 -0700 (PDT) (envelope-from avg@icyb.net.ua) Received: from edge.foundation.invalid (ool-182f9083.dyn.optonline.net [24.47.144.131]) by mta2.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) with ESMTP id <0H2Y00DSC9NZDX@mta2.srv.hcvlny.cv.net>; Tue, 24 Sep 2002 11:57:37 -0400 (EDT) Received: from localhost.foundation.invalid (localhost.foundation.invalid [127.0.0.1]) by edge.foundation.invalid (8.12.3/8.12.3) with ESMTP id g8OFvYCa081975; Tue, 24 Sep 2002 11:57:35 -0400 (EDT envelope-from avg@icyb.net.ua) Date: Tue, 24 Sep 2002 11:57:34 -0400 (EDT) From: Andriy Gapon Subject: Re: libc_r in stable In-reply-to: <3D8B1E91.B95DFC6E@FreeBSD.org> X-X-Sender: avg@edge.foundation.invalid To: Maxim Sobolev Cc: eischen@pcnet1.pcnet.com, julian@elischer.org, hackers@FreeBSD.org Message-id: <20020924115549.D81913-100000@edge.foundation.invalid> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII 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 Maxim, thanks a lot. I've also filed a PR for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=standards/43335 On Fri, 20 Sep 2002, Maxim Sobolev wrote: > Date: Fri, 20 Sep 2002 16:11:45 +0300 > From: Maxim Sobolev > To: Andriy Gapon > Cc: eischen@pcnet1.pcnet.com, julian@elischer.org, hackers@FreeBSD.org > Subject: Re: libc_r in stable > > 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. > -- 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