X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id:references :in-reply-to:content-type:content-transfer-encoding :mime-version; q=dns; s=default; b=Jb4nqDzK6MSTfp6axBCJloRvX492w 47VnFrK5RwpsVq6GCkpKUftjl/k8cflj2MsqIwq9evb1uzKvyvENo1ulE1G/S0RV wKms6///83j4mPezhiTXdgDw0Rxv/A68dHjTfDq100A01luA824BsdI+wIrnWfaC 4qpzkltKn3KFZU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id:references :in-reply-to:content-type:content-transfer-encoding :mime-version; s=default; bh=oJu7lukuo5PacNBoLZ0NGH7hZ3U=; b=H5R ABU+jf2US/wpT5wrqjaeoTmAv/wzNnBDR2S3MowS6tHWhb40OfDRpQUZ9HuiFCRv 34sbcb807WuNq8ySv0zUSSZrebAwzaxKTY/BVCWuk5ncmAcJwwgzB4vG0aSes4wS TYrHWeEPAtYZh4sWWEYY033/G6Yh40tC40kzUvis= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_20,BELOVED_BODY,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: nihxway5out.hub.nih.gov X-IronPortListener: Outbound_SMTP X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFACuIuFKcKEfW/2dsb2JhbABZgwuBDblSgR4WdIIeBwEBAQMBEig/BQsCAQgNFRQQHxMXAQ0CBA4NGoUnB4IsCKdHo2cXjnQxB4MjgRMEhHSJZJAriyiBb4E+gWgEPg From: "Lavrentiev, Anton (NIH/NLM/NCBI) [C]" To: James Johnston CC: "cygwin AT cygwin DOT com" Subject: RE: Pipe syncronization and incompatibility between Cygwin and .NET Framework 4.0 Date: Mon, 23 Dec 2013 19:05:05 +0000 Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D0C457767@MLBXv04.nih.gov> References: <02ee01cefdce$9c343300$d49c9900$@motionview3d.com> <5F8AAC04F9616747BC4CC0E803D5907D0C455040 AT MLBXv04 DOT nih DOT gov> <030c01cefff6$9c1fa3c0$d45eeb40$@motionview3d.com> In-Reply-To: <030c01cefff6$9c1fa3c0$d45eeb40$@motionview3d.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id rBNJ5lEv027234 > Check line 192 for a call to the WaitForAvailableConsoleInput function. I guess they expect hFile to be a console handle (which IS waitable). And my guess that they added the Peek intentionally to prevent the WaitFor call from slipping through (as we've seen it does, otherwise) on things that weren't supposed to be there (such as pipes). They probably know of a side effect of peeking a pipe, which makes the WaitFor API block on them (thus, still create a good cancellation point for the thread) -- again, as they would not expect a pipe there (but a good console handle; and if it isn't -- well, it's by design). But I'm only speculating here. On the other hand, I would not be surprised to learn that one team in MS would not know how to deal with the pipes and introduced a bug, easily. MS is a large company, and I witnessed such things to happen in teams of a much smaller scale, from my own experience. In our apps we use the Peek everywhere for pipe polling, and do not rely on anything else. And from Cygwin point of view, I was trying to deal with mixing native Windows things and UNIX, and it seems to be a big no-no, from the entire design point -- Cygwin is not a tool for be-friending Windows and Unix, rather a way to run your beloved GNU tools on a Windows box. Sorry you ran into this trouble... Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple