Date: Tue, 24 Sep 2002 11:57:34 -0400 (EDT) From: Andriy Gapon <avg@icyb.net.ua> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: eischen@pcnet1.pcnet.com, julian@elischer.org, hackers@FreeBSD.org Subject: Re: libc_r in stable Message-ID: <20020924115549.D81913-100000@edge.foundation.invalid> In-Reply-To: <3D8B1E91.B95DFC6E@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <sobomax@FreeBSD.org> > To: Andriy Gapon <agapon@excite.com> > 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 <eischen@pcnet1.pcnet.com> or Julian Elischer > <julian@elischer.org> (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 <agapon@excite.com> > > To: Maxim Sobolev <sobomax@freebsd.org> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020924115549.D81913-100000>