From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6622 invoked by alias); 7 Apr 2004 13:56:01 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 6143 invoked from network); 7 Apr 2004 13:55:51 -0000 Received: from unknown (HELO mehl.gfz-potsdam.de) (139.17.1.100) by sources.redhat.com with SMTP; 7 Apr 2004 13:55:51 -0000 Received: from nfw1.gfz-potsdam.de (virscan [139.17.1.10]) by mehl.gfz-potsdam.de (8.12.10/8.12.10) with SMTP id i37DtnPm017996; Wed, 7 Apr 2004 15:55:49 +0200 (MET DST) Received: from st55.gfz-potsdam.de ([139.17.157.155]) by nfw1; Wed, 07 Apr 2004 15:55:47 +0200 (CEST) Date: Wed, 07 Apr 2004 13:56:00 -0000 From: Andres Heinloo To: Mark Richards cc: gcc-help@gcc.gnu.org Subject: Re: Gnu c/c++: Alarm and read issue in linux In-Reply-To: <008a01c41bf0$8e72dd90$7101a8c0@solarwave> Message-ID: References: <008a01c41bf0$8e72dd90$7101a8c0@solarwave> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-04/txt/msg00084.txt.bz2 Hi, > My questions are: > > 1. Should alarm() work with a system call like read()? Yes, the signal handler should execute. After that the call should either continue or break with errno=EINTR (I don't remember what was the behaviour of signal() on Linux---better use sigaction() in which case you can control this behaviour). However, it only works if the driver cooperates properly with the kernel. > 2. If not, is there any work-around? Non-blocking I/O, asynchronous I/O, select(), but, again, they must be supported by the driver. If nothing else works, you can read the device in a subprocess and send the data to the main process via pipe (alarm() definitely works when you read() a pipe) or use threads. Andres.