On Aug 28, 2008, at 6:37 AM, Ralph Castain wrote:
1. specify which procs are to receive stdin. The options that were
to be supported are: all procs, a specific proc, or no procs. The
default will be rank=0 only. All procs not included will have
their stdin tied to /dev/null - which means a debugger could not
attach to the stdin at a later time.
How about: --stdin <list>, where <list> is a comma-delimited list
of integer ranges? Such as:
--stdin 0 (same as default)
--stdin 0,1 (procs 0 and 1 get stdin)
--stdin 0-9 (proc 0 through 9 get stdin)
--stdin 0-9,23-25 (procs 0 through 9 and 23 through 25 get stdin)
--stdin all (all procs get stdin)
--stdin none (no procs get stdin)
Just to be clear: is this something that is necessary, or are we
providing flexibility that nobody will ever use? Frankly, I'm told
that reading stdin at all is pretty rare, at least on jobs around
here, though I don't dispute having at least the all, one, or none
capability. But is anyone really going to pick-and-choose multiple
random procs to receive stdin?
I'm asking mostly because of the complexity it adds. Certainly, it
is doable - just wondering if it is worth the effort, or something
that will never be used.
Ah -- I actually mis-read your original comment. I'm happy with all,
none, and X (where X is a single integer).
"Go for the gold" would be the <list> syntax, but I agree that that's
not really necessary. I think it's definitely in the "would be nice"
category.
It occurs to me that we're using this <list> kind of notation in a
few places now (aren't we?). Perhaps we should have this string-
parsing code down in opal somewhere...?
Processing it is so trivial it probably doesn't merit a dedicated
code - all you do is use opal_argv_split and run down the list.
I was thinking of the ranges -- there's additional processing for the
X-Y strings. But it's moot point.
2. specify which stdxxx file descriptors you want left open on
your procs. Our defaults are to leave stdout/stderr/stddiag open
on all procs. This option would allow the user to specify that we
tie any or all of these to /dev/null
How about --stdout and --stderr, indicating which procs' stdout/
stderr you want to see? FWIW, I don't think we should provide a
way to turn off stddiag. The syntax could be just like --stdin,
except the default values would be "all".
Again, will anyone ever really use this? I agree about stddiag as
orte_show_help flows over it. I haven't found any interest around
here in shutting off stdout and/or stderr - nobody can think of a
reason to do so. Doing it is trivial - my concern here is solely
with the complexity of providing such fine-grained specifications.
It may actually be useful to turn off stdout/stderr in debugging
scenarios, meaning "I only want to see output from proc X, Y, Z."
How about leading these options off for now, but leaving the design
open to implementing them someday if someone ever cares enough?
Are these options per app context, or global? It would be awesome
to be per-app-context, but I wouldn't cry too hard if they were
global (especially if it meant making the code overly complex,
etc.).
My first reaction is that making this per app_context would create a
ton of complexity...but I'll take a gander before committing one way
or the other. Again, though, I would wonder if anyone really is
going to use this on a per app_context basis - or are we just
creating capability "because we can"?
I think it's solidly in the "because we can" department. If it's
anything more than trivial to implement, my $0.02 is to leave it off.
If someone wants to implement it someday, they can.
FWIW: as long as there's the possibility of writing an orte-iof
command line tool to suck down an individual proc's stdin/stdout/
stderr[/stddiag], I'm happy (because leaves the door open for "mpirun
--screen ...").
--
Jeff Squyres
Cisco Systems
