Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
An example of how this is done might illuminate people who still use it.
The new pselect() system call
Posted Mar 30, 2006 19:21 UTC (Thu) by clugstj (subscriber, #4020)
Posted Mar 30, 2006 19:58 UTC (Thu) by mikov (subscriber, #33179)
For comparison the Win32 API doesn't support signals.
Posted Mar 31, 2006 4:24 UTC (Fri) by hppnq (guest, #14462)
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)
Posted Mar 31, 2006 15:23 UTC (Fri) by hppnq (guest, #14462)
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.
Posted Mar 31, 2006 20:16 UTC (Fri) by giraffedata (subscriber, #1954)
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).
Posted Apr 7, 2006 13:39 UTC (Fri) by lgb (guest, #784)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds