On Fri, Sep 11, 2009 at 11:15 AM, Iruata Souza wrote: > On Tue, Sep 8, 2009 at 1:40 PM, Bakul Shah > > wrote: > > On Tue, 08 Sep 2009 08:31:28 PDT David Leimbach > 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/ > > And the FreeBSD port is underway too. It's going to have the kernel scheduling hints too it seems. Dave