From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from duke.felloff.net ([216.126.196.34]) by ur; Sat Jul  2 08:07:45 EDT 2016
Message-ID: <74e4c1cb15cfd55b308b0ea6a68bc89b@felloff.net>
Date: Sat, 2 Jul 2016 14:07:37 +0200
From: cinap_lenrek@felloff.net
To: 9front@9front.org
Subject: Re: [9front] Spew's Concurrency Extension
In-Reply-To: <CAAsuYKdk==tKjQR5vvneQzz5NKj2KiSHHmdgA9kwjH6_WwGq+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: advanced distributed reduce/map generator 

the paper states:

"A channel receive operation val = @chan is rewritten as:
recv(c, c->@out); val = c->@out;"

this is wrong, because channels are a shared resoure, and
you share the intermediate values. so if i have two processes,
doing the recive operation, they'll trash each others
c->@out values. the same applies to send of course.

say, the recv() completes on one process, then scheduler
comes it and runs the other processes recv() overriding
the @out member of the struct.

also note, that recv() can take a nil argument if you do
not need the value, but complete the recv() operation.
you do not need dummy value.

--
cinap