SIGTSTP propagation for 0.80 ?

[David Golden]

On 2005-10-04 08:57:45 -0400, Pete Wyckoff wrote:

> but left in the
> capability for a non-server concurrent master to handle other
> clients too.  I do not envision people actually doing this though.
> 

Of course, the example on the webpage suggests it. :-)

> People doing interactive work will
> probably rarely (never?) have their jobs suspended.  It would be
> very bad policy for a shared machine to do this, in my opinion.

Guess so. How infuriating would that be?  

> Coupled with the relative rarity of concurrent work,

Well, I do wonder how much rarity is simply because one
couldn't previously do it. I would think the interactive case
is where one is quite likely to want concurrency, actually,
as you're probably doing fiddly debugging and testing where
the feel of it being just a shell session where you can
C-z/fg/bg various things is nice. 

In the concurrent batch case, the advantage is presumably
"bundling" for chunkier scheduling - sticking 8 8 proc jobs of
similar length in a a 64 proc job etc, without having to amend
the code.

> that people will be using -server, I think we should just smile and
> nod and get the batch case working and tell people "don't do that"
> for interactive jobs.  Just Ctrl-z from the shell as normal.
> 

So, for that to work as normal, guess we just need
to lose the "if (!concurrent_master) raise(SIGSTOP);" from 
patch 0.80.tstp1 - needs to be just "raise(SIGSTOP);" 
- especially if the ability for a non- -server concurrent 
master to handle other clients is retained, since the most
common case is a single mpiexec which just incidentally 
happens to be a concurrent master, I guess, and it is very
annoying if the most common case can't be C-z'ed  interactively.

But then we do need make sure concurrent clients, upon a CONT, 
wait patiently for the concurrent master to CONT too instead of
things going wrong in the still-STOPped-master/CONTing-client case.

(One could get into counting clients and detecting interactive use 
and special casing, I guess, but, well, icky.)