Signals

Started by
5 comments, last by superpig 20 years, 6 months ago
OK, so I finally got around to implementing the stuff you guys gave me in the previous thread (which, of course, worked fine - Fruny''s double fork was in there, as was a custom ''daemon'' function modelled after N&V''s). Now I''m looking at writing a framework that sits on both, but I have a slight problem. Windows only provides (really) 3 messages to services - start, pause, and stop. Question is, which signals do these correspond to under Posix? SIG_STOP can''t be caught, so I figure SIG_TSTP would be stop (along with SIG_KILL, of course); pause and start/resume, though? Superpig - saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3 | Enginuity4 ry. .ibu cy. .abu ry. dy. "sy. .ubu py. .ebu ry. py. .ibu gy." fy. .ibu ny. .ebu

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

Advertisement
taking windows garbage and porting to linux = bad.

equivalent of
start: ./mydaemon
stop: killall mydaemon
pause: killall mydaemon; wait 1; ./mydaemon

The only *nix one that applies is restarting. Generally, SIGHUP is used to signal that the service should restart.
quote:Original post by C-Junkie
taking windows garbage and porting to linux = bad.

Yes, but when writing a cross-platform framework, unavoidable. I have to cater to the lower common denominator, and in this case that''s windows.

quote:
equivalent of
start: ./mydaemon
stop: killall mydaemon
pause: killall mydaemon; wait 1; ./mydaemon

The only *nix one that applies is restarting. Generally, SIGHUP is used to signal that the service should restart.


I''m talking about handling the signals in code - all you''ve got there is start/stop commands. Is there no signal sent when a process is halted (but not killed), or when it gets unhalted again?

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3 | Enginuity4
ry. .ibu cy. .abu ry. dy. "sy. .ubu py. .ebu ry. py. .ibu gy." fy. .ibu ny. .ebu

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

SIGSTOP is pause (in Unix, stop != terminate)
SIGCONT is resume
SIGTERM is stop (terminate)

When a process is stopped or terminated, its parent receives a SIGCHILD. Using sigaction for the signal handler, you can distinguish between the two.

To start the daemon, you call it. There is no "start" signal.
However a daemon can start other daemons (e.g. crond or inetd)

[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]

[edited by - Fruny on October 13, 2003 5:22:54 PM]
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
Hmm, OK.

I can''t catch SIGSTOP. Any other way of allowing my daemon to release resources on a temporary basis, short of a readme that says ''please don''t kill this process without sending SIGUSR1 first'' or something?

SIGCONT is fine... as is SIGTERM.

SIGCHILD shouldn''t be an issue, I think, because I''m using your double fork() - that detaches it from the parent process completely, doesn''t it? Either way it''d be something else (like xinetd) handling the SIGCHILD signal so I don''t think I need to worry about it (until I start spawning my own child processes, but I don''t plan to do that until I''m at least 25... ).

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3 | Enginuity4
ry. .ibu cy. .abu ry. dy. "sy. .ubu py. .ebu ry. py. .ibu gy." fy. .ibu ny. .ebu

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

quote:Original post by superpig
Is there no signal sent when a process is halted (but not killed), or when it gets unhalted again?

No such concept exists. I''ve never heard of anyone SIGSTOP/CONT''ing a daemon. Those are for interactive terminals, not daemons.

When you want a service to serve, you run it. When you don''t want the service to server, you kill it (SIGTERM). When you cahnge the cnfig file and want the service to reread it, SIGHUP is the convention.

That''s all for daemons.
OK. While it might not be something people would normally do, I still want the functionality to be available (so that you can write ''pause'' code and still call it from both Win32 and *nix), so I''ll bind it to SIGUSR1 (and ''resume'' to SIGUSR2).

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3 | Enginuity4
ry. .ibu cy. .abu ry. dy. "sy. .ubu py. .ebu ry. py. .ibu gy." fy. .ibu ny. .ebu

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

This topic is closed to new replies.

Advertisement