scsh-users
[Top] [All Lists]

Re: select() in dynamically-linked code

To: scsh-users@scsh.net
Subject: Re: select() in dynamically-linked code
From: Andreas Rottmann <a.rottmann@gmx.at>
Date: Tue, 11 Jan 2005 22:11:30 +0100
Cancel-lock: sha1:nBu21I8feXvpF9YwEAYUV5zSY+w=
List-id: <scsh-users.list-id.scsh.net>
Sender: news <news@sea.gmane.org>
Michel Schinz <Michel.Schinz@epfl.ch> writes:

> Looking at the scsh doc, I read (in section 3.9) this:
>
>   The thread system needs the timer interrupt for its own purpose, ...
>
> and I guess (without fully understanding the problem) that the reason
> curl's select() gets an EINTR is that it receives some signal used by
> the thread system. Am I right?
>
If what you describe is right (and it seems pretty plausible to me),
it means that the curl function does not catch EINTR itself, which it
arguably should; note this extract of the GNU libc manual:

,----
| A signal can arrive and be handled while an I/O primitive such as
| `open' or `read' is waiting for an I/O device.  If the signal handler
| returns, the system faces the question: what should happen next?
| 
|    POSIX specifies one approach: make the primitive fail right away.
| The error code for this kind of failure is `EINTR'.  This is flexible,
| but usually inconvenient.  Typically, POSIX applications that use signal
| handlers must check for `EINTR' after each library function that can
| return it, in order to try the call again.  Often programmers forget to
| check, which is a common source of error.
`----

There are multiple ways how to handle this, see the rest of this
section ("Interrupted Primitives").

HTH, Rotty
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?

<Prev in Thread] Current Thread [Next in Thread>