On 14 Jun 2009, at 23:52, Quentin Mathé wrote: > Le 14 juin 09 à 13:07, David Chisnall a écrit : > >> In case anyone hasn't seen this, Apple have published a few more >> details about Grand Central: >> >> http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf >> >> There is no API documentation yet, > > I bet they use NSOperation and NSOperationQueue with some new > additions. > I strongly hope at least :-) It would be a bit crazy to introduce a > new a API.
Maybe, but there is also a CoreFoundation API, so the Cocoa interface may be simpler. I'd expect something like: [[GrandCentral sharedIdlePriorityQueue] enque: myBlock]; >> but it seems that it basically >> spawns a set of threads at different priorities and uses them to run >> blocks from various queues. Lots of hype, but it doesn't seem to >> give >> anything that we can't already do with EtoileThread and clang (we >> already have an implementation of blocks and an efficient way of >> passing objects between threads - see ETThread and MKObjectPipe). > > The most interesting thing seems to be that Grand Central is system- > wide. > I suppose it consider the entire system to decide whether to create a > new thread or not, whether to schedule this operation rather this one > etc. > I'd be curious to look at what Grand Central really considers when a > choice has to be made. > It's impossible on our side to do something at the system level, but > we surely don't need that to perform well enough. The simplest way of implementing this is to have one thread for each core at each priority level (allocate them lazily when you have a non- empty queue). The reason you want it to be systemwide is that it is problematic when the machine is busy. Imagine you have two processes, each with two high-priority threads, being supplied with blocks. Each thread will have 50% of one core. The throughput will be (almost) the same as when you have just one thread per process, but the latency will be higher. Ideally, when the machine is busy you want to reduce the number of threads. We could do this if we monitored the CPU load - it doesn't really need central management; there have been a few approaches presented in the Autonomic Computing (Buzzword!) community for dealing with this. >> The most important improvement is hidden right at the bottom of the >> document; there is now a queue associated with the main thread, so >> there is a standard way of running arbitrary code at the end of the >> next run loop. > > I thought there was already a queue associated with the main thread > since -performSelectorOnMainThread:withObject:XXX is available. It's > fairly limited though, you can only pass a single argument and nothing > can be returned. If they have generalized this mechanism to allow > arbitrary message passing/queueing between threads (without resorting > to DO), this would be really nice. I thought this was a GNUstep extension. Is it in Cocoa too? David _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
