Newsgroup: it.comp.macintosh
Titolo: [Geek] Snow Leopard - Le ultime

E` tutto in inglese. Chi vuole legga, chi non vuole vada a raccogliere
le castagne, che è stagione.
**Multicore - Grand Central**
Dispatch queues and event sources are now reference counted via
retain/release API. Blocks submitted to a queue for asynchronous
execution retain the target queue until they have executed. Dispatch
event sources also retain the target queue to which they submit their
event handler Blocks.
The dispatch_call() and dispatch_call_wait() API have been removed. Two
new interfaces have been introduced: dispatch_async() and
dispatch_sync(). Callbacks should now be expressed as nested blocks.
Accessors to three "well-known" global concurrent queues with a priority
level (high, default, low) have been added. This allows Blocks to be
executed asynchronously without the application needing to create a
specific queue for them. Blocks submitted to the high priority queue
will be executed before blocks submitted to the default priority queue,
and so on. Dispatch queues created by the application may also set their
priority level.
Dispatch event sources now report error codes via the the
dispatch_event_t argument to event handler Blocks. Applications should
check the event for errors using the dispatch_event_get_error() API
inside their event handler Blocks. Once a dispatch event source reports
an error, it will never deliver any additional event handler Blocks and
may be released by the application.
Monitoring the same underlying Grand Central object (i.e. process
identifier, signal, file descriptor) from multiple dispatch event
sources may have unreliable results.
Running the following two commands in Terminal will provide additional
information Grand Central:
headerdoc2html -o ~/Desktop/libdispatch_core
/usr/include/dispatch/core.h
headerdoc2html -o ~/Desktop/libdispatch_events
/usr/include/dispatch/events.h
**Multicore - Blocks**
Syntax Changes
The existing syntax of bracketing "by reference" variables between '|'
(bar) symbols is deprecated and will be removed. There is a new form of
storage available, __block storage, and it is on par with register,
auto, and static for local variables. The new syntax is:
void foo() {
__block int i = 0; // "i" lives in block storage
void (^myblock)(void) = ^{ printf("is is now: %d\n", ++i); };
myblock(); // i is now: 1
myblock(); // i is now: 2
}
A Block literal (e.g. ^{ … }) is implemented as the address of a stack
local data structure that represents the Block. The stack local data
structure has scope of the enclosing compound statement. The following,
for example, should be avoided:
void bar() {
void (^blockArray[3])(void); // an array of 3 block references
for (int i = 0; i < 3; ++i) {
blockArray[i] = ^{ printf("hello, %d\n", i); }; // INCORRECT: block
literal scope is "for loop"
}
}
It is now possible to use a global Block literal
int GlobalInt = 0;
int (^getGlobalInt)(void) = ^{ return GlobalInt; };
**C++ support**
- Blocks are now supported in C++ and ObjC++
- Within a member function references to member variables and functions
are via an implicitly imported "this" pointer and thus appear mutable.
During a Block_copy the literal value of the "this" pointer is copied so
memory management of the object must be done carefully.
- A stack based C++ object that is referenced within a block must have a
const copy constructor. During a Block_copy a const copy will be made
into the heap storage. Two known issues are there is no destructor
called on the stack based block const copy and under Garbage Collection
the heap based destructor is not invoked.
Debugger support
- It is possible to set breakpoints and single step into Blocks.
- Blocks can now be invoked from within a gdb session:
$ invoke-block myblock 10 20
- Note that C strings need to be passed in the form "\"this string\""
- Block storage starts out on the stack just like Blocks do and is
copied to the heap when either a Block_copy (or in ObjC a -copy message)
is performed. Thus, the address of a __block variable can change over
time.
**64-bit Kernel**
The early 2008 models of the Mac Pro, 15" and 17" MacBook Pro and Xserve
can be used for 64-bit kernel development. Audio and AirPort are now
enabled on these on these testing configurations. In SnowLeopard, the
64-bit kernel is is used by default on the Xserve and the Mac Pro and
MacBook Pro systems can be booted into the 64-bit kernel in one of two
ways:
1) Temporarily boot into the 64-bit kernel by holding down "6" and "4"
while powering on the machine
2) Run `sudo nvram boot-args="arch=x86_64" ` to set the 64-bit kernel as
your default kernel, and append any other debugging flags you may need,
such as "debug=0x144". To revert back to the 32-bit kernel as the
default, you can run `sudo nvram -d boot-args`.
This seed contains the necessary support for porting kexts to 64-bit and
developers are strongly encouraged to do so.
Known Limitations in the 64-bit kernel:
- Shark does not work on the 64-bit kernel.
- Sleep / wake and power management is not currently supported. It is
recommend that you disable sleep in System Preferences.
- Graphics acceleration is not yet supported which may cause programs
which require graphics acceleration to run incorrectly.
- Some behavior which was previously unsupported, such as modifying a
collection while enumerating it, and attempting to modify a kext's
__TEXT segment, now results in diagnostic kernel panics.
-- 
I've always been more concerned with users. )\._.,--....,'``.
Programmers do their work but once, while  /,   _.. \   _\  (`._._,
users are saddled with it ever thereafter. `_.-(,_..'--(,_..'`-.;.'

 can be used for 64-bit kernel development.
Il 13" non è figlio di Maria?

 Il 13" non č figlio di Maria?
afaik SL non ha ancora il motore grafico a punto, sicchč maybe
o magari piů semplicemente non ci sono ancora abbastanza dev con il
MBLate08 around
ammazza come parlo aho`


 Il 13" non č figlio di Maria?
Nemmeno i MacPro late 2006...
-- 
Per rispondere, togliere -NOSPAM- dall'indirizzo.