How to interrupt a fread call?

Question

I have the following situation:

There is a thread that reads from a device with a fread call. This call is blocking as long as there is no data send from the device. When I stop this thread it remains hanging inside this thread.

Now I found the following inside the man page of fread:

ERRORS

On all systems that conform to the Single UNIX Specification, the fread() function sets errno as listed for the following conditions:

[EINTR] The read operation was terminated due to the receipt of a signal, and no data was transferred.

That would mean there is a way to interrupt the call from a different thread. But I have no idea how. Can someone tell me how to send a signal to interrupt the fread call? And what signal I need to send?

---

Update 08-10-10 09:25

I still haven't got it to work. I tryed the kill() and pthread_kill() with different signals. But nothing seems to interrupt the fread() call. The only thing that I got working is killing the entire application, but that's not what I want.

Discontinuity

Interesting that this has to do with concurrency: I misread fread as a Cockney "thread". – Meatball

use read instead of fread – Drava

Answer 1

1. Signals:

Using signals, as many others pointed out, would work. However, as many others also pointed out, the approach has its disadvantages.

2. Select():

Using select() (or other multiplexing function), you can block waiting for data to arrive from more than one file descriptor, and specify a timeout.

Use the timeout to your advantage. Whenever select() returns, check a global variable to see if you must terminate. If you want immediate reaction, keep reading.

3. Select() and pipes:

Multiple fds means you can wait for data arriving through the device you mentioned and, say, a pipe.

Before you create the thread, create a pipe, and then have the thread block on select() monitoring both the device and the pipe. Whenever you want to unblock select whether the device has new data or not, send a byte down the pipe.

If select() tells you it unblocked due to data arriving through the pipe, you can clean up and terminate. Note this method is much more flexible than the signaling method, since you can, besides just using the pipe as a wake-up method, use it to pass useful information or commands.

4. Select(), pipes and signals:

If you are using multiple processes and don't want to/can't pass around a pipe, you can combine both solutions. Create a pipe and install a signal handler for, say, SIGUSR1. In the signal handler, send a byte down the pipe.

Whenever a process sends SIGUSR1, the handler will be called and unblock select(). By examining the fdsets, you will know it was for no other reason than your own program signaling itself.

Hunkydory

Wouldn't select() be insufficient because fread() might make multiple calls to read()? I wonder if maybe getting the stream into an error state in a signal handler would work... – Phrygia

Answer 2

You really want to read about the select(2) system call, which will allow you to find out whether there is data available on that file descriptor, without blocking at all or without blocking on only that device.

Infelicity

While select() would be useful, it's not really answering the question. – Macrophage

@Michael Foukarakis - Given the context, the question may be asking for the wrong solution to the larger problem. John gave a reasonable answer to help the OP reach his goal by addressing the larger problem. Downvote seems a bit harsh. – Metric

I can't judge the solution without knowing the problem, can I? Maybe the OP has to use fread(). I don't know, and I'd rather not assume. – Macrophage

fread is buffered, so select could block indefinitely even though there is data available to be read – Reforest

Answer 3

Take a look at man 2 kill. (Or see here)

I get the feeling that you don't want to do this, though--most of the time people ignore errno EINTR and read again. You might want to look into non-blocking reads instead.

Schindler

Can you tell me what signal I need to send with the kill() system call to interrupt the fread()? – Discontinuity

Generally speaking, any signal will interrupt the fread() call. That said, generally speaking, many signals will usually also kill your application (except SIGCONT). I would use SIGHUP or one of the user-defined signals personally. But like I said in my answer, I also don't usually like using signals at all for this purpose. (See John Marshall's answer for an alternative) – Schindler

In addition to generating a signal from another thread with kill, the alarm function is often used to cause a blocking read call to time out. – Pectinate

@Ben Voigt: yes, and I still think it's ugly every time I see it. – Conceit

@ninjalj: Not disagreeing with you, I much prefer to use poll or aio, which have all the benefits of select with none of the clunky argument setup logic. But it's useful to know patterns such as use of alarm to set a timeout on a blocking i/o call so you recognize them when reading existing code. – Pectinate

Answer 4

In the thread, instead of blocking with fread, block with select. When select returns, check an "am I done" variable. If not done, you can call fread to get the data.

From the other thread -- that wants to stop the fread thread -- you can set the "am I done" variable and then close the fd so that the fread thread will wake up from select immediately.

If your context prohibits you from closing the fd (you mention you're reading from a device, but say you had a socket you wanted kept open), you could open a second fd that you write to from the other thread to wake up select.

As suggested in the comments below, closing the fd to wake up select may not be portable. You can use the second-fd strategy mentioned above to achieve this more portably.

Metric

Or you could close() the fd passed to select() in order to cancel it immediately, instead of using context-switching cache-missing battery-wasting polling logic. – Pectinate

@Ben Voigt - Thanks for pointing that out. Edited my answer accordingly. – Metric

@Ben: très cool, but is it specified to work that way? I skimmed the select(2) and Threads sections of the SUS spec, but didn't notice any description of what to expect to see when an fd is disappeared out from under it while select() is blocking. OTOH I suppose something sensible had better happen or else there is a potential for exploits... – Infelicity

@John: seems that select is supposed to return EBADF under such conditions, but if that strikes you as non-portable bstpierre is already on the right track for another approach that is just slightly more work: pass a second file descriptor to select where the second one can be written to (instead of closed) in order to wake the thread early. – Pectinate

fread may do its own buffering, so select could wait indefinitely while there is data available to be read with fread – Reforest

Answer 5

You can use the kill() syscall.

UPDATE

Turns out I misread your question. As R. pointed out below, kill() is only for killing processes, not threads.

Ladonnalady

Can you tell me what signal I need to send with the kill() system call to interrupt the fread()? – Discontinuity

It has to be a signal for which you have previously set up a signal handler (see sigaction()) and have not used the SA_RESTART flag. – Eucalyptol

kill will not work. You need pthread_kill which can send the signal to a specific thread. – Selene

kill() is ok if the signal is blocked in the other threads. – Eucalyptol

Answer 6

Signal handlers will not interrupt fread unless they were installed as interrupting, and unhandled signals are never interrupting. The POSIX standard allows handlers installed by the signal function to be wither interrupting or non-interrupting by default (and on Linux the default to non-interrupting), so if you need a specific behavior, use the sigaction function and specify the desired sa_flags. In particular, you need to omit the SA_RESTART flag. For example:

struct sigaction sa = { .sa_handler = dummy_func, .sa_flags = 0 };
sigaction(SIGUSR1, &sa, 0);

Note that sa_flags would implicitly be 0 anyway if omitted, but I included it explicitly in the initializer to illustrate. Then you can interrupt the fread by sending SIGUSR1 with kill or pthread_kill.

Selene