Subject: /dev/null, /dev/full?

From: [email-masked] (Jon Flower)
Date: Mon, 8 Feb 93 07:35:05 PST

To: [email-masked]
Re: /dev/null, /dev/full?

Despite the fact that we still don't seem to have settled on a model
for specifying process identifiers I would like to raise a different
issue on this topic ..... the idea of having a special identifier for
a node that doesn't actually exist.

Sending a message to this destination would always succeed and return
as though the data were transmitted, and reading from this node would
also return immediately, without modifying the user buffer, but with a
return code indicating that no error occurred.

I think this offers users great simplifications in their coding.
A classic example is the standard domain decomposed PDE solution. In
one dimension you have to write code for the guard strip exchange 
such as

	if(I_am_on_left_edge) {
	    send_to_right();
	    read_from_right();
	}
	else if(I_am_on_right_edge) {
	    send_to_left();
	    read_from_left();
	}
	else if(there_is_more_than_one_node) {
	    send_to_right();
	    read_from_right();
	    send_to_left();
	    read_from_left();
	}

Note that this code assumes buffered communication. If you have
to code unbuffered messages then the logic becomes considerably worse
since you have to deal with even and odd parity and the case of an
odd number of nodes, etc.....

If we have the "no node" concept then the above becomes:

	send_to_right();
	read_from_right();
	send_to_left();
	read_from_left();

in all cases. Given an "exchange" or "sendrecv" function this code
becomes even simpler.

When dealing with virtual topologies this is invaluable because the
virtual topology code can return this special value as the process
I.D. and it can then be passed directly to the communication routines
without having to be interpreted at all. 

I think this can be implemented without cost to the higher level
software by making the "no node" identifier illegal for normal
communication. Then the basic communication functions which, 
I imagine, do checking such as

	if( ! destination_is_legal_node ) {
		return ILLEGAL_NODE;
	}

can be simply changed to

	if( ! destination_is_legal_node ) {
		if( destination_is_no_node ) {
			/* Pretend this was OK */
		    return OK;
		}
		return ILLEGAL_NODE;
	}

without any impact on the regular code.

EXTENSION:
    Marc Snir raised an interesting point in connection with this idea.

    Since it is normally used to deal with boundary conditions 
    in the physical world why not extend the idea by allowing a read 
    from the "no node" source to actually implement the user boundary 
    condition either by filling an array with predefined values, or 
    even calling a user-defined function?

    Again I think this could be implemented at no cost to the higher 
    levels by simply invoking some code in the error handling for
    normal communication, and extending the "no node" identifier to
    a range of identifiers. I think in this case you might also be
    able to run user-supplied code, even when you have a communication
    co-processor, assuming that the error checking shown above
    occurs early enough in the sequence that it would still be in the
    main processor(?)

    I don't have any experience with this extension but it certainly
    seems "cute". One possible objection might be that the boundary
    case code is almost certainly already coded in any existing
    application and pushing it down into the message passing layer
    might be a step backwards. For applications written from 
    scratch, however, it is a nice abstraction.

	Jon Flower