From mboxrd@z Thu Jan  1 00:00:00 1970
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
In-reply-to: Your message of "Tue, 08 Sep 2009 08:31:28 PDT."
	<3e1162e60909080831g728ced86wcd143865e37da2f9@mail.gmail.com>
References: <5d375e920909030815n74e481f4yad9814f478db5a78@mail.gmail.com>
	<25CF9336-C071-44A5-AB04-6BB042BC5755@kix.in>
	<h7um5r$f0v$1@panix1.panix.com>
	<5d375e920909070240x6b4dabe3x6c47ad11b303525f@mail.gmail.com>
	<3e1162e60909080831g728ced86wcd143865e37da2f9@mail.gmail.com>
From: Bakul Shah <bakul+plan9@bitblocks.com>
Date: Tue,  8 Sep 2009 09:40:02 -0700
Message-Id: <20090908164003.3D1DD5B3B@mail.bitblocks.com>
Subject: Re: [9fans] "Blocks" in C
Topicbox-Message-UUID: 6aa0b4bc-ead5-11e9-9d60-3106f5b1d025

On Tue, 08 Sep 2009 08:31:28 PDT David Leimbach <leimy2k@gmail.com>  wrote:
>
> Having wrestled with this stuff a little bit, and written "something".  I
> can immediately see how one can get away from needing to "select" in code so
> much, and fire off blocks to handle client server interactions etc.  It's
> kind of neat.

alt(3) is a nicer way to avoid select().

I still say CSP is the way to go. In plan9/limbo channels
work across coroutines in one process. Seems to me extending
channels to work across preemptive threads (running on
multiple cores) or across processes or machines is might lead
to a more elegant and no less performant model.  It seems
to be a more natural model when you have zillions of
processors on a chip (like TileraPro64, with zillion = 64).
They can't all go to shared external memory without paying a
substantial cost but neighbor to neighbor communication is
far faster (tilera claims 37Tbps onchip interconnect b/w and
50Gbps of I/O bw).

It is nice that a Apple C block treats all non local
variables (except __block ones) as read only variables.  But
every time I look at blocks I see new problems. What if a
block calls a function that modifies a global like in the
example below? If this works, what is the point of treating
globals as readonly? If this doesn't work, how do ensure
trash_x() causes a seg fault, particularly when it is defined
in another file?

int x;

void trash_x() { x = -42; }

... ^{ trash_x(); } ...

My view: if you can't solve a problem cleanly and in a
general way with a feature, it does not belong in a language
(but may belong in a library).