The new pselect() system call [LWN.net]

The new pselect() system call

Posted Mar 30, 2006 19:21 UTC (Thu) by clugstj (subscriber, #4020) [Link]

OK, but first someone must explain to me what the signal is being used for. Then I will try to come up with a design that doesn't require a signal to perform this function. Usually, in the past, what I've seen is signals being used for timeouts. This is easily avoided by using select/poll (which have timeout parameters) before calling read/write instead of blocking in read/write.

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.

The new pselect() system call

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. :-)

System Call Interruption

Posted Mar 31, 2006 13:30 UTC (Fri) by clugstj (subscriber, #4020) [Link]

System call interruption is not portable. Some UNIXes will restart some system calls after they handle the signal, some won't. Yes, signals are OK in non-threaded applications, but when the application uses threads, the race-condition nightmare begins.

System Call Interruption

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

Portability is not an issue when your system call is actually interrupted. :-)

The complexity that arises from mixing signals and threads is only justified if you have specific reasons to implement it like that. By default, a multi-threaded process acts the same as a non-threaded process when interrupted.

So, unless you have specific reasons for defining per-thread signal masks (which is possible), there's nothing special about the multi-threaded case.

The new pselect() system call

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).

The new pselect() system call

Posted Apr 7, 2006 13:39 UTC (Fri) by lgb (guest, #784) [Link]

I've met with this problem when I wrote my little server capable of serving incoming requests with spawning special programs with fork() and than exec(). The "main" process is to handle accept(), and initialize communication between my server and the clients connecting, and when enough data is ready sent by client, I should start an external program and manage the data flow between it and my server. Of course I should keep track processes I've forked so SIGCHLD is needed. And I don't want to create new process for each incoming connection neither threads (I want my software run on both of Solaris and Linux, and I've learned that forking from multithtread application is not a very fast and portable way to do things), so I've decided to use nonblocking I/O and select(), also because of the need of taking care about my childs, signal handling is a must for me.