Le 15 juin 09 à 01:11, David Chisnall a écrit : > On 14 Jun 2009, at 23:52, Quentin Mathé wrote: > >> Le 14 juin 09 à 13:07, David Chisnall a écrit : >> >> >> 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];
Yes. This could be written as an NSOperationQueue extension though: [[NSOperationQueue sharedIdlePriorityQueue] addBlock: 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. I see. > 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. ok >> 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? It is. I just took at the Cocoa documentation, these methods were introduced in Mac OS X 10.2. What I didn't know is that they also introduced new related methods in Mac OS X 10.5 (probably not yet implemented on GNUstep): -performSelector:onThread:withObject:waitUntilDone: -performSelector:onThread:withObject:waitUntilDone:modes: -performSelectorInBackground:withObject: Cheers, Quentin. _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
