From owner-freebsd-standards Wed Oct 23 14:10: 4 2002 Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 862D837B401 for ; Wed, 23 Oct 2002 14:10:03 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CCE843E65 for ; Wed, 23 Oct 2002 14:10:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id g9NLA3x3010108 for ; Wed, 23 Oct 2002 14:10:03 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id g9NLA2hV010107; Wed, 23 Oct 2002 14:10:02 -0700 (PDT) Date: Wed, 23 Oct 2002 14:10:02 -0700 (PDT) Message-Id: <200210232110.g9NLA2hV010107@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org Cc: From: Andriy Gapon Subject: Re: standards/43335: libc_r: execve() and close-on-exec flag, interrupted write() Reply-To: Andriy Gapon Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The following reply was made to PR standards/43335; it has been noted by GNATS. From: Andriy Gapon 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