The new pselect() system call

Posted Mar 30, 2006 19:58 UTC (Thu) by mikov (subscriber, #33179) [Link]

I completely agree. Signals should be avoided if possible - there are countless race conditions and apparentlky even buggy glibc functions (!) associated with them. To me signals have always seemed like a remnant from the past when they were used to supplement a lacking API. If anything the API should evolve to decrease the need for signals even further.

For comparison the Win32 API doesn't support signals.

Posted Mar 31, 2006 4:24 UTC (Fri) by hppnq (guest, #14462) [Link]

Mmmh, I like the fact that system calls can be interrupted. :-)

Signals can be used for notifying process groups asynchronously of some event, for instance, which is likely to be a bit more tricky to do with select(). Yes, this is ancient Unix, but so is the concept of the tty.

Using select() as a replacement for signal handling is a quite tricky hack that only solves one specific problem and creates a couple of others, so I'm glad work is being done to implement the appropriate, standard interface. :-)

Posted Mar 31, 2006 20:16 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

How about the most basic use of signals: I have a server that waits for input on various sockets and I want to terminate the server. Sending SIGTERM is a conventional way to do that. I know it well, I know the tools ('kill') to do it like the back of my hand, and it works the same on most other processes, so it is very convenient for it to work on the server in question.

If the server is simple enough, the author doesn't have to write any code at all; the kernel will terminate it all by itself. If the server wants to e.g. finish up transactions in progress, the author can add a small amount of code to handle SIGTERM. But without signals, the author must write more code and design a special termination protocol. I then must remember to use it, and probably look up how to use the tool that initiates it, every time I want to terminate the server.

There are similar external interruption sort of things where signals are easier to implement and easier for the user to deal with. Think about a program in which a user types commands. One of those commands is taking too long and he wants to abort and go back to the program's command prompt. Ctl-C is an excellent way for him to interrupt, and rather easy to implement (Ctl-C normally generates a signal).

Signals also cut through layers. Let's say I run a program that calls a library function that calls a library function and so on and 5 levels deep there is a select(). I don't know or want to know anything about those deep libraries, but I know I don't want to wait more than 4 seconds for everything to finish. With a signal, I can get that select() to abort after 4 seconds without even knowing it's there. The only other way would be to add timeouts in every parameter list in the stack, and have every level keep track of elapsed time. More work for everybody.

I think of signals, when properly used with the modern interfaces, to solve the same problems that interrupts and "throwing" objects do.

Timeout, on the other hand, is what is misplaced on the select() call. Timing out should be handled either through a signal (it would have to be different from the existing global signals, so that you could use it inside a library) or a file descriptor that becomes ready at a certain time (not unlike the self-sending pipe thing that subsitutes for signals).