On Tue, Sep 8, 2009 at 1:40 PM, Bakul Shah <bakul+pl...@bitblocks.com> wrote:
> On Tue, 08 Sep 2009 08:31:28 PDT David Leimbach <leim...@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).
>
for those who still care
http://libdispatch.macosforge.org/
