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"
>> 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,
> 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