Unix Signals (and sockets, and pipes, and stuff)

[Barnaby W. Füi]

There's some really great stuff on google about implementing signals, what to look out for, etc. What I can't seem to find is an overview of when it is good and bad to use them. They are meant for interprocess communication, but alot of people seem to use sockets for such things. If I don't really need such complexity (i.e. just "which signal did I get?"), it seems that signals are fine, yet I don't know if this is still "dirty" or "wrong" or whatever.

 

[takwong]

can you post where in google talks about implementing signals?

thanks,
tak

 

[Nothinman]

I would say signals are best used for triggering certain things (like HUP for re-reading config, USR1 for increasing debug level, USR2 for decreasing debug level, etc), for real interprocess communication and sharing of data you'd need something like a socket.

 

[Barnaby W. Füi]

Links:

http://www-users.cs.umn.edu/~bentlema/unix/advipc/ipc.html
http://www.perl.com/doc/manual/html/pod/perlipc.html
http://users.actcom.co.il/~choo/lupg/tutorials/signals/signals-programming.html

I would say signals are best used for triggering certain things (like HUP for re-reading config, USR1 for increasing debug level, USR2 for decreasing debug level, etc), for real interprocess communication and sharing of data you'd need something like a socket.

It's about along those lines. It is for Thump (look down), basically, HUP makes it skip to the next song (on each song it checks file mtimes and re-reads them if needed), INT is stop, STOP is pause, CONT is resume, etc. To me it seemed like a perfect fit, I mean, why reinvent the wheel? But then again, I don't want to use a round peg in a square hole. There isn't really any need to send actual text between processes, just a few different signals to trigger different things.

 

[manly]

It depends on your definition of IPC, but I wouldn't say signals are for application-level IPC.

They're simply software interrupts, basically so that you can trigger events asynchronously.

The fact that you can implement very simple IPC with signals should not entrench them as a general solution. But I haven't done a lot of UNIX programming, so this is just my opinion based on memory.

 

[Barnaby W. Füi]

I'm not at all opposed to the idea that they are a wrong fit for this use, I'm just curious exactly why.

 

[Nothinman]

handling STOP and CONT would probably break job control in the shell it's run from, atleast you wouldn't be able to use ctrl+z - bg.

 

[Barnaby W. Füi]

Originally posted by: Nothinman
handling STOP and CONT would probably break job control in the shell it's run from, atleast you wouldn't be able to use ctrl+z - bg.

It is a daemon, so no worries about that. (But yes, if you run it with -nodaemon, and then pause/resume from elsewhere, its shell gets a bit funky, but that's ok, it's not how it normally should be run.)

edit: oh, and it doesn't handle STOP/CONT, it just lets them happen as normal (STOP makes the music stop playing, CONT picks up right where it left off, no work needed by me ). The difference is that the frontends send those signals to pause/resume, and that's where it gets a little weird when in nodaemon mode.

 

[singh]

There's some really great stuff on google about implementing signals, what to look out for, etc. What I can't seem to find is an overview of when it is good and bad to use them. They are meant for interprocess communication, but alot of people seem to use sockets for such things. If I don't really need such complexity (i.e. just "which signal did I get?"), it seems that signals are fine, yet I don't know if this is still "dirty" or "wrong" or whatever.

Signals should be used when you are NOT going to be doing IPC frequently. Signals are also not a good choice when you need to transfer a lot of data. Lastly, signals are a bad idea for software that has to run on multiple platforms. Use sockets, they are available for all major OS's.

 

[Barnaby W. Füi]

Originally posted by: singh
Signals should be used when you are NOT going to be doing IPC frequently.

Yeah, that's the case here.

Signals are also not a good choice when you need to transfer a lot of data.

ANY data, really. Unless you want to send signals in binary, SIGUSR1 SIGUSR2 SIGUSR1 SIGUSR1 SIGUSR1 SIGUSR2 etc I can't imagine how slow that'd be.

Lastly, signals are a bad idea for software that has to run on multiple platforms. Use sockets, they are available for all major OS's.

Eh, windows and os9, not really too worried about either. It looks like sockets will probably be getting involved at some point, but it will be because I can do alot more with them.

 

[singh]

Eh, windows and os9, not really too worried about either. It looks like sockets will probably be getting involved at some point, but it will be because I can do alot more with them.

I know you like to program in python (you freak ) which can easily run on multiple platforms, so I mentioned keeping cross-platform compatibility in mind

 

[Barnaby W. Füi]

I assume that if I want a file-based socket, then I need to use a unix domain socket? Or am I thinking of this the wrong way? (TCP on a "file" just seems odd to me.)

 

[Barnaby W. Füi]

Actually a named pipe / fifo looks like the best fit for this.

I definitely have plans for sockets though, now that I've done some reading. Check this out:

import SocketServer

class MyHandler(SocketServer.StreamRequestHandler):
def handle(self):
text = self.rfile.readline(8192).strip()
self.wfile.write(text)

if __name__ == "__main__":
server = SocketServer.TCPServer( ("localhost", 54321), MyHandler)
server.serve_forever()

% telnet localhost 54321
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hi
hiConnection closed by foreign host.

 

[Spyro]

Originally posted by: BingBongWongFooey
Actually a named pipe / fifo looks like the best fit for this.

I definitely have plans for sockets though, now that I've done some reading. Check this out:

import SocketServer

class MyHandler(SocketServer.StreamRequestHandler):
def handle(self):
text = self.rfile.readline(8192).strip()
self.wfile.write(text)

if __name__ == "__main__":
server = SocketServer.TCPServer( ("localhost", 54321), MyHandler)
server.serve_forever()

% telnet localhost 54321
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hi
hiConnection closed by foreign host.

Whoa Way 2 cool. I'll have to look this up

Me = Python Newbie

 

[Barnaby W. Füi]

Woo, finally figured out how to get around fifos blocking.

import os
name = "/tmp/foobar"
if os.path.exists(name): os.unlink(name)
os.mkfifo(name)

wr = os.open(name, os.O_RDWR|os.O_NDELAY)
rd = os.open(name, os.O_RDONLY|os.O_NDELAY)

os.write(wr, "one\n")
os.write(wr, "2\n")
os.write(wr, "three\n")

try:
print os.read(rd, 1024).strip()
except OSError, (foo, bar):
print "no data %s || %s" % (foo,bar)

% ./fifo.py
one
2
three

One small step for BBWF, one giant leap for interprocess communication