sends don't block, right?

[Shawn Pearce]

Joe, thanks for a nicely written reply.

So long as the developer is programming using send/recv (like with
gen_tcp), they will most likely synchronize with the other process,
and consequently ensure the message queues are emptied at frequent
intervals.

Really I was just a little concerned about the caller blocking up
due to buffers being jammed everywhere except on the target process'
message queue, so that the caller could do:

	gen_serial:send(Port, << ... >>),
	case gen_serial:recv(Port, 8, 3000) of
	{ok, Data} ->
		...
	{error, timeout} ->
		error_logger:error_report(...)
	end.

and be sure that the recv call is where they will block.  From what
everyone has told me, this is basically what will happen.

You make a good arguement for !!, but do you really mean to suggest that
the above should be written as:

	Port ! {send, << ... >>},
	case Port !! {recv, 8, 3000} of
	{ok, Data} ->
		...
	{error, timeout} ->
		error_logger:error_report(...)
	end.

?

I'm quite sure I find the syntax ugly, at least in this case.  :)
But then again, this is like a file IO process, it shouldn't be
seen by the user; or the user shouldn't know its there.  If my driver
was a linked-in driver I wouldn't even need the process at all.


Joe Armstrong <joe@REDACTED> wrote:
> Asynchronous sends  are find - but you  need to take a  little care to
> make sure you can't go into infinite send loops (like you program) and
> that if you are doing a load of asynchronous sends then you interleave
> the odd RPC to synchronize things again.
> 
>   If  you do  a whole  bundle of  asynchronous sends  and then  an RPC
> things will  get synchronized  at the RPC  and the buffers  should not
> saturate - this is of course only true between pairs of processes.
> 
>   I now love my !! operator - and program clients with
> 
> 	A ! B         and 
> 	Val = A !! B
> 
>   operators
> 
>   I program the servers like this:
> 
> 	receive
> 	    {replyTo, Pid, ReplyAs, Q} ->
> 		...
> 		Pid ! {ReplyAs, Val}
> 		...
> 	    Msg -> 	
> 		...
> 
>   And don't use any stub routines (horrors).
> 
>   Robert  (Virding)  first  programmed  the  I/O  routines  with  this
> replyTo-replyAs style - it's very nice ...
> 
>   Now I don't write interface  functions that abstract out the message
> passing interface. That way I can clearly "see" the message passing.
> 
>   If you use !!  at the top  level of your code then you can "see" the
> RPC - my brain goes (RPC this  might be slow - take care, and RPC this
> will synchronize any outstanding asynchronous  message) - so I can see
> what I'm doing.
> 
>   Burying this *inside*  a stub function which hides  the RPC makes me
> loose sight of the important fact that we are doing an RPC. If the RPC
> is  "off site"  (ie  we do  an  RPC on  a remote  node)  then we  have
> abstracted  away  from  the  single  most important  detail  that  the
> programmer should no about.
> 
>   Non-local RPCs cause great performance hits.
> 
>   When I see this in my code:
> 
> 	Pid @ Node !! X
> 
>   I think <<danger very slow>>
> 
>   with
> 
> 	Pid !! X
> 
>   I think <<possibly slow take care>>
> 
>   but
> 
> 	X ! Y
> 
>   I thing <<ok but I'll need to synchronize later>>
> 
>   Hiding  this  essential  detail  in  a  stub  routine  seems  to  be
> abstracting away  from the one essential  detail that we  need to know
> about when writing distributed programs.

-- 
Shawn.

  I had no shoes and I pitied myself.  Then I met a man who had no feet,
  so I took his shoes.
  		-- Dave Barry