Date: Wed, 23 Oct 2002 14:10:02 -0700 (PDT) From: Andriy Gapon <agapon@excite.com> To: freebsd-standards@FreeBSD.org Subject: Re: standards/43335: libc_r: execve() and close-on-exec flag, interrupted write() Message-ID: <200210232110.g9NLA2hV010107@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR standards/43335; it has been noted by GNATS. From: Andriy Gapon <agapon@excite.com> To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: standards/43335: libc_r: execve() and close-on-exec flag, interrupted write() Date: Wed, 23 Oct 2002 16:57:13 -0400 (EDT) Valentin, what you caught is actually a broader issue, it is my belief that it can not be resolved using existing libc_r architecture. The need for libc_r to have all descriptors non-blocking undercovers results in a real mess when sharing the descriptors between processes, since there can not be any reliable knowledge of what is going on in other process. Possible solution could be an extension to system calls with an addtional parameter specifying mode only for a current call, so that libc_r could specifically request non-blocking operation on a descriptor in blocking mode( or something like that). Maybe this can be emulated by putting a blocking descriptor into non-blocking mode and back imeediately before and after an operation on the descriptor. This can work because the descriptors are not supposed to be used concurrently by multiple processes anyway, they need to syncronize somehow. -- Andriy Gapon * "Never try to outstubborn a cat." Lazarus Long, "Time Enough for Love" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210232110.g9NLA2hV010107>