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 Message-ID: <3D8B1E91.B95DFC6E@FreeBSD.org> References: <20020915231311.J53171-100000@edge.foundation.invalid>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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?3D8B1E91.B95DFC6E>