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=JTyx6W9duEUkOLZzD/bnw+PHTWshX /I0ZCsi9ojVufDDMXi6QqgCWzEb+K7VjO87y1yqwqbfXAye4sYU2oiV8McawnsDu 9/45I75aDSEBkkDVDulsJbhdVKQVvlB2GNvqJ/Z5m6vCmeg0/qqxspby6P+4uRcD zO8rSekuv9M4lo= 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=0lbcZJZcNWmXcUa8/K0+Hr1Odu0=; b=GiU Evb4MRAuD7DY9TApIDOtgOVMurZ/ThK6QKTxNUmV8ZLGSfTNktxYuwcJBKXm9yWM jU+HFNitUidBUwarYTRC0rCcgC0ygQVZQkRULhtcPQ75tGW9v5pBy8QXm62AGi28 JMmjYub81XV46zKcBoPxRq0NYBSPFtQyUahQMpuo= 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=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: nihxway6out.hub.nih.gov X-IronPortListener: Outbound_SMTP X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEALvGtFKcKEep/2dsb2JhbABZg0NVuHVPgTN0giYBAQQSKD8QAgEIIhQQHxMlAgQODRqHYg2nJKMJF45hMQeDI4ETBI5Yim6QZIFtgT6CKg 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: Fri, 20 Dec 2013 22:39:18 +0000 Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D0C455040@MLBXv04.nih.gov> References: <02ee01cefdce$9c343300$d49c9900$@motionview3d.com> In-Reply-To: <02ee01cefdce$9c343300$d49c9900$@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 rBKMdYcb015879 MSDN does not list pipe handles as waitable with WaitForMultipleObjectsEx (only a user comment at the end does). If you trace execution without PeekNamedPipe(), you'll see that WaitForMultipleObjectsEx() returns immediately, and that it is ReadFile() that blocks and waits for the input (which will be supplied after 3 seconds). --quote-- The WaitForMultipleObjectsEx function can specify handles of any of the following object types in the lpHandles array: Change notification Console input Event Memory resource notification Mutex Process Semaphore Thread Waitable timer --quote-- Also from here: http://stackoverflow.com/questions/14203618/windows-api-wait-for-data-to-be-available-on-non-gui-console-input-pipe-based --quote-- Is it possible to wait for data to be available on a non-GUI-based console input? The issue is that WaitFor* methods do not support PIPE handles and therefore STDIN is not supported if the process input is fed from another process, e.g. using the pipe | functionality of cmd. The only way I know to query a pipe for data without actually reading the data is to use PeekNamedPipe(), but then you lose the ability to wait on a timeout effectively, because it has no timeout so you would have to implement a manual loop instead. --quote-- HTH, 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