On Fri Sep 18 11:52:23 EDT 2009, driv...@0xabadba.be wrote:
> Is there some method of lock profiling on plan9? For example when I do
> work on freebsd and say remove a giant lock from the keyboard subsystem; I
> run the lock profiler before and after the change to see how long the system
>
(undergrad) on these kind of topics and am interested
in seeing how I may be of use.
=jt
--Original Message--
From: erik quanstrom
Sender: 9fans-boun...@9fans.net
To: 9fans@9fans.net
ReplyTo: Fans of the OS Plan 9 from Bell Labs
Subject: Re: [9fans] "Blocks" in C
Sent: Sep 18,
> it isn't really a `big kernel lock' in the linux sense.
you're right, technically it is a very different problem.
the effects seem similar. the lock is just in the block allocator
rather than the syscall interface. if you're doing a lot of i/o
in a standard kernel, there's a lot of block allo
> i mentioned that the pool library can act as a big
> kernel lock a few weeks ago. i don't know if anyone
> has thoughts on how to deal with this.
it isn't really a `big kernel lock' in the linux sense.
the big kernel lock was the device by which operating systems
written with only a uniprocesso
It would be easy to say that list should be divided, in practice
though, I'm not sure the folks who I would like to have a privilege
of addressing would voluntarily subscribe to the #3 type of list.
Being a curious sometime user I guess I fall in category 3. Which
seems natural since the list
On Thu, 2009-09-17 at 17:02 -0400, erik quanstrom wrote:
> > ... In case anyone is wondering what they could be doing instead of feeding
> > this massive thread more fatty foods.
>
> there's lots of complaining on the list about the
> content of the list.
>
> it's not like there aren't good meaty
> what happened with either of the recently-reported
> fossil lockup problems, for instance?
As I now have two servers at home (old and new) I have been trying
to provoke the old one into locking up so I can take a snap of its fossil.
sadly the old server has been irriatingly reliable and the onl
http://ninetimes.cat-v.org/news/2009/09/07/0-mplayer9/
On Thu, Sep 17, 2009 at 10:31 PM, Anant Narayanan wrote:
> On Sep 17, 2009, at 10:26 PM, erik quanstrom wrote:
>>>
>>> Good luck trying to get Plan 9 to play video!
>>>
>>
>> minooka; lc /sys/src/9/pc/*tv*.c
>> devtv.c vgatvp3020.c
> ... In case anyone is wondering what they could be doing instead of feeding
> this massive thread more fatty foods.
there's lots of complaining on the list about the
content of the list.
it's not like there aren't good meaty issues to discuss.
what happened with either of the recently-reported
> What I was referring to was Plan 9's ability
> (or lack thereof) to decode and play digital video codecs. Just one of those
> things that prevent someone from running only Plan 9 on their computers --
> you need one of the big 3 for web browser + video.
With Cinap Lenrek's work on linuxemu, one
On Sep 17, 2009, at 10:26 PM, erik quanstrom wrote:
Good luck trying to get Plan 9 to play video!
minooka; lc /sys/src/9/pc/*tv*.c
devtv.c vgatvp3020.cvgatvp3026.c
Sure, if you have a TV tuner. What I was referring to was Plan 9's
ability (or lack thereof) to decode and play di
> Good luck trying to get Plan 9 to play video!
>
minooka; lc /sys/src/9/pc/*tv*.c
devtv.c vgatvp3020.cvgatvp3026.c
- erik
Not meaning to add fuel to the fire, but;
On Sep 17, 2009, at 7:38 PM, Jack Norton wrote:
I hate iTunes with a passion. It is a huge monolithic godlike
creature that tries to do everything for me (usually when I don't
want it to). It brings my 12" powerbook to a screeching halt (I get
beac
David Leimbach wrote:
On Thu, Sep 17, 2009 at 1:43 AM, Charles Forsyth
mailto:fors...@terzarima.net>> wrote:
we'd have been much better off if Apple had instead spent the
time and effort writing a decent iTunes, or opening their platform
interfaces enough that someone else could
On Sep 17, 2009, at 3:19 AM, Andrew Simmons wrote:
And no doubt we'd have been much better off if Apple had instead
spent the
time and effort making a decent iPod.
Um... what is it you dislike about the iPod?
—
Daniel Lyons
On Thu, Sep 17, 2009 at 1:43 AM, Charles Forsyth wrote:
> we'd have been much better off if Apple had instead spent the
> time and effort writing a decent iTunes, or opening their platform
> interfaces enough that someone else could do it (and on Linux, not just Mac
> or Windows).
>
>
What's your
Like shuffle db (i.e. no iTunes).
On Thu, Sep 17, 2009 at 5:19 AM, Andrew Simmons wrote:
> >> we'd have been much better off if Apple had instead spent the
> >> time and effort writing a decent iTunes
>
> And no doubt we'd have been much better off if Apple had instead spent the
> time and effor
>> we'd have been much better off if Apple had instead spent the
>> time and effort writing a decent iTunes
And no doubt we'd have been much better off if Apple had instead spent the
time and effort making a decent iPod.
The iTunes on my computer strikes me as at worst perfectly decent, in
genera
On Sep 17, 2009, at 2:43 AM, Charles Forsyth wrote:
opening their platform interfaces
Any in particular?
—
Daniel Lyons
we'd have been much better off if Apple had instead spent the
time and effort writing a decent iTunes, or opening their platform
interfaces enough that someone else could do it (and on Linux, not just Mac or
Windows).
For those that care:
http://www.friday.com/bbum/2009/08/29/basic-blocks/
http://www.friday.com/bbum/2009/08/29/blocks-tips-tricks/#more-1505
--
l...@iridescent.org
Apple has an "interesting" process for releasing open source code. One of the
guys that works on it wrote something up on it once, but I am sorry I don't
have a pointer right now.
I would not assume that the it's the same "bits" that are used inside Apple.
Certainly at the very least, many comm
On Sat, Sep 12, 2009 at 4:08 AM, Anant Narayanan wrote:
> On Sep 11, 2009, at 10:36 PM, Roman V Shaposhnik wrote:
>
>> I still do care very much (and in fact, I've been meaning
>> to provide some of the answers on this mailing list, but
>> apparently one can't upgrade to Snow Leopard over the
>>
On Sep 11, 2009, at 10:36 PM, Roman V Shaposhnik wrote:
I still do care very much (and in fact, I've been meaning
to provide some of the answers on this mailing list, but
apparently one can't upgrade to Snow Leopard over the
net so I have to physically drive to the Mac store :-().
Anyway, for a
On Fri, Sep 11, 2009 at 1:36 PM, Roman V Shaposhnik wrote:
> On Fri, 2009-09-11 at 15:15 -0300, Iruata Souza wrote:
> > On Tue, Sep 8, 2009 at 1:40 PM, Bakul Shah
> > >
> wrote:
> > > int x;
> > >
> > > void trash_x() { x = -42; }
> > >
> > > ... ^{ trash_x(); } ...
> > >
> > > My view: if you c
On Fri, 2009-09-11 at 15:15 -0300, Iruata Souza wrote:
> On Tue, Sep 8, 2009 at 1:40 PM, Bakul Shah wrote:
> > 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 belon
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 ca
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
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 o
On Tue, Sep 8, 2009 at 5:31 PM, David Leimbach wrote:
>
> [snip]
>
> I guess we'll see what happens.
We all know what will happen: more and more layers of crud will be added.
Just as Russ predicted:
From: r...@plan9.bell-labs.com (Russ Cox)
Subject: Re: [9fans] design clairvoyance & the 9 way
Da
On Mon, Sep 7, 2009 at 2:40 AM, Uriel wrote:
> On Mon, Sep 7, 2009 at 11:05 AM, Greg Comeau wrote:
> > In article <25cf9336-c071-44a5-ab04-6bb042bc5...@kix.in>,
> > Anant Narayanan wrote:
> >>I understand the argument that blocks don't "feel" C-like, but the
> >>argument that you can do everythi
On Mon, Sep 7, 2009 at 11:05 AM, Greg Comeau wrote:
> In article <25cf9336-c071-44a5-ab04-6bb042bc5...@kix.in>,
> Anant Narayanan wrote:
>>I understand the argument that blocks don't "feel" C-like, but the
>>argument that you can do everything with just using function pointers
>>is BS.
>
> Even on
In article <8214db3a-3368-4b61-b0cd-bac5f2be7...@sun.com>,
Roman Shaposhnik wrote:
>There's been a *lot* of speculation on this thread and very little fact.
>I'd encourage everybody to play with the feature before forming
>any kind of final judgement.
This is true, a good point, etc, however
In article <25cf9336-c071-44a5-ab04-6bb042bc5...@kix.in>,
Anant Narayanan wrote:
>I understand the argument that blocks don't "feel" C-like, but the
>argument that you can do everything with just using function pointers
>is BS.
Even one step further, even if we all agree blocks are BS,
moving
On Sun, Sep 6, 2009 at 4:03 PM, Uriel wrote:
> On Fri, Sep 4, 2009 at 4:56 PM, David Leimbach wrote:
> >
> >
> > On Fri, Sep 4, 2009 at 7:20 AM, erik quanstrom
> > wrote:
> >>
> >> > I could be wrong, but I feel like you're not really interested in
> >> > entertaining that this idea could be use
On Sun, Sep 6, 2009 at 3:35 PM, Uriel wrote:
> On Thu, Sep 3, 2009 at 9:50 PM, David Leimbach wrote:
> >
> >
> > On Thu, Sep 3, 2009 at 12:36 PM, erik quanstrom
> > wrote:
> >>
> >> > > > Apple's using it all over the place in Snow Leopard, in all their
> >> > > > native
> >> > > > apps to write
On Fri, Sep 4, 2009 at 4:56 PM, David Leimbach wrote:
>
>
> On Fri, Sep 4, 2009 at 7:20 AM, erik quanstrom
> wrote:
>>
>> > I could be wrong, but I feel like you're not really interested in
>> > entertaining that this idea could be useful, but more interested in
>> > shooting
>> > it down [...]
>>
On Thu, Sep 3, 2009 at 9:50 PM, David Leimbach wrote:
>
>
> On Thu, Sep 3, 2009 at 12:36 PM, erik quanstrom
> wrote:
>>
>> > > > Apple's using it all over the place in Snow Leopard, in all their
>> > > > native
>> > > > apps to write cleaner, less manual-lock code. At least, that's the
>> > > > c
On Thu, Sep 3, 2009 at 5:54 PM, erik quanstrom wrote:
>> Plan 9 has a lot to offer and a lot for others to learn from. Concurrency
>> framework that could scale up to 1K [virtual]cores in an SMP
>> configuration is not one of those features though.
>
> forgive the ignorance, but is there any such t
On Fri, 2009-09-04 at 13:42 -0400, erik quanstrom wrote:
> as i believe was originally explained,
> i ripped that example *directly* from the apple grand central
> documentation on page 37 in the "Data Types" section:
>
> http://developer.apple.com/mac/library/documentation/Performance/Reference/G
> as i believe was originally explained,
> i ripped that example *directly* from the apple grand central
> documentation on page 37 in the "Data Types" section:
>
> http://developer.apple.com/mac/library/documentation/Performance/Reference/GCD_libdispatch_Ref/GCD_libdispatch_Ref.pdf
>
> maybe you
> Where exactly does it say that?
>
> >dispatch_block_t p;
> >
> > if(cond){
> > p =^ { print("cond\n"); };
> > }else{
> > p =^ { print("cond\n"); };
> > }
> > p();
> >
> > since the first part is equivalent to
> >
> > if(cond){
> > s
On Sep 4, 2009, at 9:58 AM, Iruata Souza wrote:
On Fri, Sep 4, 2009 at 1:44 PM, Roman Shaposhnik wrote:
There's been a *lot* of speculation on this thread and very little
fact.
(...)
Trust me, I've seen how it is generated.
so we should trust you and not the facts? is that what you are sayi
On Fri, Sep 4, 2009 at 1:44 PM, Roman Shaposhnik wrote:
> There's been a *lot* of speculation on this thread and very little fact.
> (...)
> Trust me, I've seen how it is generated.
>
so we should trust you and not the facts? is that what you are saying?
because i haven't seen any 'factual' code y
On Sep 4, 2009, at 2:15 AM, Greg Comeau wrote:
In article <1251993672.16936.4779.ca...@work.sfbay.sun.com>,
Roman V Shaposhnik wrote:
On Thu, 2009-09-03 at 08:44 -0700, David Leimbach wrote:
The blocks aren't interesting at all by themselves, I totally agree
with that. However what they do t
On Sep 4, 2009, at 5:14 AM, erik quanstrom wrote:
But this has no more to do with parallelism than any other
feature of C. If you used __block vars in a block, you'd
still need to lock them when the block is called from
different threads.
that's a lot worse than a function pointer. with
a func
There's been a *lot* of speculation on this thread and very little fact.
I'd encourage everybody to play with the feature before forming
any kind of final judgement.
On Sep 3, 2009, at 8:52 PM, erik quanstrom wrote:
Did you even read the article or any of the examples? There are
plenty
of thin
On Fri, 04 Sep 2009 08:04:40 PDT David Leimbach wrote:
> On Fri, Sep 4, 2009 at 7:41 AM, Bakul Shah
>
> > wrote:
>
> > On Fri, 04 Sep 2009 00:47:18 PDT David Leimbach
> > wrote:
> > > On Fri, Sep 4, 2009 at 12:11 AM, Bakul Shah
> > > <
> > bakul%2bpl...@bitblocks.com >
> > > > wrote:
> > >
>
On Fri, Sep 4, 2009 at 7:41 AM, Bakul Shah
> wrote:
> On Fri, 04 Sep 2009 00:47:18 PDT David Leimbach
> wrote:
> > On Fri, Sep 4, 2009 at 12:11 AM, Bakul Shah
> > <
> bakul%2bpl...@bitblocks.com >
> > > wrote:
> >
> > > But this has no more to do with parallelism than any other
> > > feature of
On Fri, Sep 4, 2009 at 7:20 AM, erik quanstrom wrote:
> > I could be wrong, but I feel like you're not really interested in
> > entertaining that this idea could be useful, but more interested in
> shooting
> > it down [...]
>
> remember, if a guy says to the king, hey you're fly's undone,
> we se
On Fri, 04 Sep 2009 00:47:18 PDT David Leimbach wrote:
> On Fri, Sep 4, 2009 at 12:11 AM, Bakul Shah
>
> > wrote:
>
> > But this has no more to do with parallelism than any other
> > feature of C. If you used __block vars in a block, you'd
> > still need to lock them when the block is called fr
> I could be wrong, but I feel like you're not really interested in
> entertaining that this idea could be useful, but more interested in shooting
> it down [...]
remember, if a guy says to the king, hey you're fly's undone,
we send that guy to the stockades for a week. meanwhile
the king's fly r
I could be wrong, but I feel like you're not really interested in
entertaining that this idea could be useful, but more interested in
shooting it down. That's fine, people do that all the time. People
are *constantly* saying Plan 9 is a huge waste of time too. And if
you count the number
On Fri, Sep 4, 2009 at 5:14 AM, erik quanstrom wrote:
> > But this has no more to do with parallelism than any other
> > feature of C. If you used __block vars in a block, you'd
> > still need to lock them when the block is called from
> > different threads.
>
> that's a lot worse than a function
> But this has no more to do with parallelism than any other
> feature of C. If you used __block vars in a block, you'd
> still need to lock them when the block is called from
> different threads.
that's a lot worse than a function pointer. with
a function pointer your going to get unique space
o
In article <3e1162e60909030844r8760a8fu1b27d6e60965e...@mail.gmail.com>,
David Leimbach wrote:
>The blocks aren't interesting at all by themselves, I totally agree with
>that. However what they do to let you write a function inline, that can be
>pushed to another function, to be executed on a con
In article <1251993672.16936.4779.ca...@work.sfbay.sun.com>,
Roman V Shaposhnik wrote:
>On Thu, 2009-09-03 at 08:44 -0700, David Leimbach wrote:
>
>> The blocks aren't interesting at all by themselves, I totally agree
>> with that. However what they do to let you write a function inline,
>> that
In article ,
erik quanstrom wrote:
>> Apple's using it all over the place in Snow Leopard, in all their native
>> apps to write cleaner, less manual-lock code. At least, that's the claim
>> :-).
>
>could someone explain this to me? i'm just missing how
>naming a block of code could change its lo
In article <5d375e920909030832i17c62bc7mbb1afc55708e0...@mail.gmail.com>,
Uriel wrote:
>So libthread must be a figment of 9fan's imagination...
>
>Of course, for Apple (or anyone else) to learn from Plan 9 would be
>impossible, so instead they had to add a new 'feature' to C.
Apple, and many othe
On Fri, Sep 4, 2009 at 12:11 AM, Bakul Shah
> wrote:
> On Thu, 03 Sep 2009 22:35:35 PDT David Leimbach
> wrote:
> >
> >
> > Actually, reading on a bit more they deal with the "variable capture"
> > talking about const copies.
> >
> > Automatic storage variables not marked with __block are impor
On Thu, 03 Sep 2009 22:35:35 PDT David Leimbach wrote:
>
>
> Actually, reading on a bit more they deal with the "variable capture"
> talking about const copies.
>
> Automatic storage variables not marked with __block are imported as
> const copies.
>
> The simplest example is that of importin
On Fri, 04 Sep 2009 00:44:35 EDT erik quanstrom wrote:
> > > that sucker is on the stack. by-by no-execute stack.
I don't think so. See below.
> > > how does it get to the stack? is it just copied from
> > > the text segment or is it compiled at run time?
> > >
> >
> > I don't think I posted
On Thu, Sep 3, 2009 at 10:31 PM, David Leimbach wrote:
>
>
> On Thu, Sep 3, 2009 at 9:44 PM, erik quanstrom wrote:
>
>> > > that sucker is on the stack. by-by no-execute stack.
>> > > how does it get to the stack? is it just copied from
>> > > the text segment or is it compiled at run time?
>>
On Thu, Sep 3, 2009 at 9:44 PM, erik quanstrom wrote:
> > > that sucker is on the stack. by-by no-execute stack.
> > > how does it get to the stack? is it just copied from
> > > the text segment or is it compiled at run time?
> > >
> >
> > I don't think I posted the whole code, so that's my bad.
> > that sucker is on the stack. by-by no-execute stack.
> > how does it get to the stack? is it just copied from
> > the text segment or is it compiled at run time?
> >
>
> I don't think I posted the whole code, so that's my bad. The X was on the
> stack to begin with as the first X was an aut
On Thu, Sep 3, 2009 at 8:52 PM, erik quanstrom wrote:
> > Did you even read the article or any of the examples? There are plenty
> > of things that you can "do" with blocks that you can't with just
> > function pointers. That's besides the fact that some of them are more
> > elegantly expressed wi
> Did you even read the article or any of the examples? There are plenty
> of things that you can "do" with blocks that you can't with just
> function pointers. That's besides the fact that some of them are more
> elegantly expressed with blocks that look sort of ugly with function
> pointe
On Sep 3, 2009, at 5:15 PM, Uriel wrote:
Exactly, I still fail to understand the point of this "feature",
function points have worked fine for ages, but then I never understood
any religion, and that is what Apple seems to be all about.
Did you even read the article or any of the examples? Ther
On Thu Sep 3 21:38:30 EDT 2009, driv...@0xabadba.be wrote:
> To ensure only one thread in the kernel at a time?
yes. http://en.wikipedia.org/wiki/Giant_lock
it allows only one kernel thread to run at a time.
the pool lock allows as many threads to run as
one would like, but they can't allocate
To ensure only one thread in the kernel at a time?
-jt-
--Original Message--
From: erik quanstrom
Sender: 9fans-boun...@9fans.net
To: 9fans@9fans.net
ReplyTo: Fans of the OS Plan 9 from Bell Labs
Subject: Re: [9fans] "Blocks" in C
Sent: Sep 3, 2009 21:32
> what does BLK st
> what does BLK stand for?
big kernel lock.
- erik
> i'll grant you this in implementation. the pool library's lock
> in effect becomes plan 9's BLK. since the pool library is used
> in the kernel and user space, a user space application gets hit
> twice. i've been doing some full-tilt boogie testing with 2x10gbe
> and even with 2 cores, the BLK
On Thu, 2009-09-03 at 12:44 -0400, erik quanstrom wrote:
> On Thu Sep 3 12:20:09 EDT 2009, r...@sun.com wrote:
> > On Thu, 2009-09-03 at 11:54 -0400, erik quanstrom wrote:
> > > > Plan 9 has a lot to offer and a lot for others to learn from.
> > > > Concurrency
> > > > framework that could scale
On Thu, 2009-09-03 at 17:35 -0400, erik quanstrom wrote:
> On Thu Sep 3 17:09:01 EDT 2009, r...@sun.com wrote:
> > Anything can be done using regular C and threads. The trick here
> > is to make everything *scalable* and *painless* enough so that
> > mere mortals can start benefiting from parallel
On Sep 3, 2009, at 10:02 AM, erik quanstrom wrote:
in c, i don't see why such a bolt-on would be useful in
c, especially since your concurrent fifo would be limited
to one shared-memory node unless you're going to add a runtime
compiler.
It's primarily an aesthetic benefit. From
http://arst
On Sep 3, 2009, at 9:44 AM, David Leimbach wrote:
I'm not 100% sure why the heck they did it this way, which is
totally different from any other version of concurrent programming
setup I've seen, except maybe that Apple likes to "think different"?
This API looks a lot to me like doing even
On Thu, Sep 3, 2009 at 2:45 PM, David Leimbach wrote:
>
>
> On Thu, Sep 3, 2009 at 2:35 PM, erik quanstrom wrote:
>
>> On Thu Sep 3 17:09:01 EDT 2009, r...@sun.com wrote:
>> > Anything can be done using regular C and threads. The trick here
>> > is to make everything *scalable* and *painless* en
On Thu, Sep 3, 2009 at 2:35 PM, erik quanstrom wrote:
> On Thu Sep 3 17:09:01 EDT 2009, r...@sun.com wrote:
> > Anything can be done using regular C and threads. The trick here
> > is to make everything *scalable* and *painless* enough so that
> > mere mortals can start benefiting from parallelis
On Thu, Sep 3, 2009 at 2:49 PM, David Leimbach wrote:
>
>
> On Thu, Sep 3, 2009 at 2:45 PM, David Leimbach wrote:
>
>>
>>
>> On Thu, Sep 3, 2009 at 2:35 PM, erik quanstrom wrote:
>>
>>> On Thu Sep 3 17:09:01 EDT 2009, r...@sun.com wrote:
>>> > Anything can be done using regular C and threads. T
Roman V Shaposhnik wrote:
> On Thu, 2009-09-03 at 11:54 -0400, erik quanstrom wrote:
>> even commodity intel and amd mp offerings are numa.
>> they're not very n, but they're still n.
>
> True. But even for those platforms good SMP frameworks are quite
> difficult to come by. And here I do mean c
On Thu Sep 3 17:09:01 EDT 2009, r...@sun.com wrote:
> Anything can be done using regular C and threads. The trick here
> is to make everything *scalable* and *painless* enough so that
> mere mortals can start benefiting from parallelism in their code.
>
> The other trick here is to find a model t
On Thu, 2009-09-03 at 15:36 -0400, erik quanstrom wrote:
> > > > Apple's using it all over the place in Snow Leopard, in all their native
> > > > apps to write cleaner, less manual-lock code. At least, that's the
> > > > claim
> > > > :-).
> > >
> > > could someone explain this to me? i'm just m
On Thu, Sep 3, 2009 at 4:50 PM, David Leimbach wrote:
>
>
> On Thu, Sep 3, 2009 at 12:36 PM, erik quanstrom
> wrote:
>>
>> > > > Apple's using it all over the place in Snow Leopard, in all their
>> > > > native
>> > > > apps to write cleaner, less manual-lock code. At least, that's the
>> > > > c
On Thu, Sep 3, 2009 at 12:36 PM, erik quanstrom wrote:
> > > > Apple's using it all over the place in Snow Leopard, in all their
> native
> > > > apps to write cleaner, less manual-lock code. At least, that's the
> claim
> > > > :-).
> > >
> > > could someone explain this to me? i'm just missing
> > > Apple's using it all over the place in Snow Leopard, in all their native
> > > apps to write cleaner, less manual-lock code. At least, that's the claim
> > > :-).
> >
> > could someone explain this to me? i'm just missing how
> > naming a block of code could change its locking properties.
>
On Thu, Sep 3, 2009 at 11:58 AM, erik quanstrom wrote:
> > Apple's using it all over the place in Snow Leopard, in all their native
> > apps to write cleaner, less manual-lock code. At least, that's the claim
> > :-).
>
> could someone explain this to me? i'm just missing how
> naming a block of
On Thu, Sep 3, 2009 at 9:02 AM, erik quanstrom wrote:
> > The blocks aren't interesting at all by themselves, I totally agree with
> > that. However what they do to let you write a function inline, that can
> be
> > pushed to another function, to be executed on a concurrent FIFO, is where
> > the
> Apple's using it all over the place in Snow Leopard, in all their native
> apps to write cleaner, less manual-lock code. At least, that's the claim
> :-).
could someone explain this to me? i'm just missing how
naming a block of code could change its locking properties.
- erik
On Thu Sep 3 12:20:09 EDT 2009, r...@sun.com wrote:
> On Thu, 2009-09-03 at 11:54 -0400, erik quanstrom wrote:
> > > Plan 9 has a lot to offer and a lot for others to learn from. Concurrency
> > > framework that could scale up to 1K [virtual]cores in an SMP
> > > configuration is not one of those
On Thu, 2009-09-03 at 11:54 -0400, erik quanstrom wrote:
> > Plan 9 has a lot to offer and a lot for others to learn from. Concurrency
> > framework that could scale up to 1K [virtual]cores in an SMP
> > configuration is not one of those features though.
>
> forgive the ignorance, but is there any
> The blocks aren't interesting at all by themselves, I totally agree with
> that. However what they do to let you write a function inline, that can be
> pushed to another function, to be executed on a concurrent FIFO, is where
> the real power comes out.
this reminds me of paul and byron's shell
On Thu, 2009-09-03 at 08:44 -0700, David Leimbach wrote:
> The blocks aren't interesting at all by themselves, I totally agree
> with that. However what they do to let you write a function inline,
> that can be pushed to another function, to be executed on a concurrent
> FIFO, is where the real p
> Plan 9 has a lot to offer and a lot for others to learn from. Concurrency
> framework that could scale up to 1K [virtual]cores in an SMP
> configuration is not one of those features though.
forgive the ignorance, but is there any such thing as a
1k-core smp machine? and is apple doing such a th
On Thu, 2009-09-03 at 17:32 +0200, Uriel wrote:
> So libthread must be a figment of 9fan's imagination...
>
> Of course, for Apple (or anyone else) to learn from Plan 9 would be
> impossible, so instead they had to add a new 'feature' to C.
Plan 9 has a lot to offer and a lot for others to learn
On Thu, Sep 3, 2009 at 8:15 AM, Uriel wrote:
> On Wed, Sep 2, 2009 at 4:20 PM, Devon H. O'Dell
> wrote:
> > 2009/9/2 Uriel :
> >> On Wed, Sep 2, 2009 at 10:04 AM, Anant Narayanan wrote:
> >>> Mac OS 10.6 introduced a new C compiler frontend (clang), which added
> >>> support for "blocks" in C [1]
So libthread must be a figment of 9fan's imagination...
Of course, for Apple (or anyone else) to learn from Plan 9 would be
impossible, so instead they had to add a new 'feature' to C.
uriel
On Wed, Sep 2, 2009 at 5:07 PM, David Leimbach wrote:
> Has anyone actually looked at the spec or is th
On Wed, Sep 2, 2009 at 4:20 PM, Devon H. O'Dell wrote:
> 2009/9/2 Uriel :
>> On Wed, Sep 2, 2009 at 10:04 AM, Anant Narayanan wrote:
>>> Mac OS 10.6 introduced a new C compiler frontend (clang), which added
>>> support for "blocks" in C [1]. Blocks basically add closures and anonymous
>>> functions
In article ,
Akshat Kumar wrote:
>Greg Comeau wrote:
>[... stuff ...]
>
>These four posts seem to be in indirect
>conversation with Charles Forsyth's,
>"one thing that gets me is that i've had
>people fulminate about the few minor
>changes in Plan 9's C compilers,
>because `they are not standard'.
>Perhaps he [me?] can further elaborate.
i certainly did not have comeau in mind.
Greg Comeau wrote:
[... stuff ...]
These four posts seem to be in indirect
conversation with Charles Forsyth's,
"one thing that gets me is that i've had
people fulminate about the few minor
changes in Plan 9's C compilers,
because `they are not standard'"
Perhaps he can further elaborate.
a
1 - 100 of 117 matches
Mail list logo
