Hm, before unusual SIGTSTP usages, we should discuss normal SIGTSTP usages.

The most normal way to suspend a foreground job (aka process group) is this.

 0. Send SIGTSTP to the process group, which do the default behavior.
    (such as kill(-pgid, SIGTSTP))

If the process group needs some work before suspension,
the most foreground process of the process group will
do one from following.

 1. Simulate tty SIGTSTP.  If the process wants to suspend, send SIGTSTP
    to its own process group.
    (such as kill(0, SIGTSTP))

 2. Trap SIGTSTP, do something, reset signal hander and resend SIGTSTP
    to itself.

A SIGTSTP usage other than above is just a corner case or an accident.

Since 1. is the most often the case that requires SIGTSTP handling,
we need kill(0, SIGTSTP) anyway.

The case 2. we can use either kill(getpid(), SIGTSTP) or kill(0, SIGTSTP).
I'd recommend kill(0, SIGTSTP) here since
 - we can share the same code with 1.,
 - code is simpler,
 - it behaves better (for users) in the corner cases.


OK, then, let's discuss the corner cases.

mouse@Rodents.Montreal.QC.CA writes:
> >>> As for SIGTSTP and other tty signals, the signal should be sent to
> >>> the process group rather than to just the current process.
> >> I disagree.
> > Take a look at curses(3) and other SIGTSTP-aware software.  You will
> > easily find kill(0, SIGTSTP).
> 
> So?  Just because other software is broken is no reason for us to write
> more broken software.  (I wasn't aware of this bug in curses; it really
> ought to be fixed.  Thanks for pointing it out.)

What is the benefit of ``fixing'' programs to be less safe to users?

> > Stopping only one process of a process group will cause serious
> > problems with BSD job control and must be avoided.
> 
> Right.  So?  As I wrote, if it was generated from the tty, it's already
> been sent to the rest of the process group.  If it was generated with
> kill(), then either it's already been sent to the rest of the process
> group or it shouldn't be sent to the rest of the process group.

As you notice, it is not needed, but does no harm.  So this is OK.

> > BSD is carefully designed to allow kill(0, SIGTSTP) in the former
> > case.  Sending SIGTSTP to already stopped processes is ignored
> > happily.
> 
> Yes...if the process happens to be stopped at that point.  Which it may
> not be, for any of various reasons.

I admit it is a waste, but better than leaving terminal unusable when
the SIGTSTP is sent to this process specifically.  It is impossible
for the process to distinguish the cases.

> > In the latter case ["If it was sent to this process specifically"],
> > stopping one process of a process group may left the terminal in
> > unusable state, and stopping the process group is user's benefit.
> 
> That's as may be.  But it is not for us to make that decision; that is
> for the signal's sender to decide.  If the signal was sent to us and no
> other process, it is not for us to say that it should be rebroadcast to
> others; we should behave as much as possible like a process with no
> handling installed, which does *not* include re-sending the signal

You can use SIGSTOP (not SIGTSTP) for that purpose.
SIGSTOP works even on orphaned process groups.

Regards,
-- 
ITOH Yasufumi