---
title: WWDC2001 Session 140
framework: wwdc
role: article
path: wwdc/wwdc2001-140
---

# WWDC2001 Session 140

## Transcript

Kind: captions Language: en surprised more people than I thought would survive till this time on Friday thanks to the marquee decide we're here to talk about the colonel at 3:30 on Friday no exciting demos to give it's just me you and hopefully we can cover some topics that you guys are really concerned about so let's get this thing going here where is it up there it is okay it's over here so what are you going to learn today well the main thing you're going to learn is what the basic colonel services are that are available to you as programmers you're also going to learn some of the layering that goes on above those services inside of our system one of the things that you know we've been able to talk about for the last few years here at WWDC is you know this really cool kernel technology we have this year part of the message is yeah we have really cool technology don't use it right so how are you gonna use it well you're going to use the layers that are built above it you're gonna mostly be writing Carbon applications or cocoa applications your some of you are going to be writing BSD applications and wrapping them as you just saw right to give them the user experience of a higher-level application right and we want to show you how some of those services are are layered above ours what you're going to learn is you know when it's safe to directly call some of our services right and when it's not safe to call some of our service what those higher-level services are that are available to you through the hire frameworks right to use those instead all right and the one of the key things that that this session is going to teach you is all right although you're not going to be directly programming to very many of our services in the kernel all right when it comes time to do debugging right you're going to have to know what's happening at those lower levels of the system because the debuggers tend to jump you in at some of the lowest levels and you have to work your way back up right and so if you don't know how a thread is tied to some of the higher level services then you're going to be in trouble alright again the same thing when you're trying to tune your application right you have to understand how everything is put together how the low level services are used by the frameworks that you're writing to in order to get the correct performance characteristics that you're looking for what you're not going to learn here right we're not going to talk about how to build file system cats right there was another session right a lot of people come to the kernel session saying great I'm gonna learn about all about how to program in the kernel well you're gonna learn about the services we provide and some of those are available to catch traders as well but then they're rapid in a whole different set of services some obscuring some of ours promoting some of their own we're not here just specifically to talk about how to write one of those right nor are we here to talk about how to write a networked kernel extension the networking sessions covered most of that and in general we're not here to talk about how to write in the program in the kernel alright that while a lot of this applies the same services are available in the kernel again you're going to tend to be in one of those specialized environments either an i/o kit extension or a filesystem extension or potentially and network text and when you're in each of those environments the view on these services is different you can do some of these things you can't do some of these things that we're going to talk about and some of the in kernel programming environments access to these services are spelled a little bit differently or take a few different parameters we're not going to get into those right so who's who would this book before then this session right and it's for all those people who are out there writing applications today right that they need to understand how to get the most out of your program and the kernel services that it's using will tell you how to get the best performance and how to understand all of that is what we're here for same thing text developers you may learn a little bit but you're not going to learn the details of how to do your work and power users I mean when you run some of the performance tools hopefully some of you made it to the performance section performance tool section you're going to see a lot of things going on in the system right it helps to understand how they're put together with the lower-level services where Darwin is the lowest level of Mac os10 everything that happens in Mac OS 10 to some extent or another is mitigated managed controlled by the Darwin layer and in the Darwin layer right the kernel part is the most critical part okay so some of the general truths about being in a Mac OS 10 application the first is that every application that's a native application in Mac OS 10 is a bsd process alright it's not that some of them are some of them aren't if you can see them if they're an application you can see them and manage them and control them as BSD processes and because of the way we implemented our kernel most beasts of all processes are actually mock tasks as well so inside of the darwin kernel there's a layering of mock and BSD and so every process is a mock task it owns and controls a mock task right and one of the things you're also going to notice and be very tempted by is the fact that the API is for all of these different layers tend to be available everywhere right you know if you happen to be writing carbon CFM application will then maybe not everywhere but other than that you look at the headers and you look at the frameworks and there's a lot of api's available to you right and one of the things you have to do is is try to stick to the highest level service that you can for what programming environment you're in use the services available there they tend to map on to the lower level services right and if you stick to those you're going to be much better off alright so what you've seen probably a few times already today is this picture of the Darwin kernel right where it talks about file systems and networking and and the i/o kit drivers that are available and that you can write well we're not really here to talk about those bubbles that are there here to talk about the background everything else right the services that the kernel provides that lets those things and all the applications do what they have to do right and again you've traditionally seen this division of the mach kernel versus the bsd part of the kernel right we tend to think of those as while there is a distinction and we try to keep the formal layering there right what we're concerned about is the services that the kernel provides to you as developers and how to make those services the best the best matching to the semantics of the higher-level applications that we can write and so we tend to say well we don't have these distinctions right what we have is you know one kernel that provides these services in a layered fashion right and the basic services are process management threading scheduler file management not necessarily the file systems itself but everything that the file systems use in order to interact with the rest of the system and managing files virtual memory inter process communication and security so why don't we start digging through some of these things oh wait first that's right I forgot where'd all these things come from right well the kernel is actually a collection of technologies from essentially three groups of places the Mach 3o provides the foundation for a lot of what goes on in the kernel especially virtual memory scheduling and IPC the the bsd portion the main bsd portion of our code was picked up from the for for lights project right and that gives us a process model our scheduling our file access and then we picked up most of the networking code from various flavors of freebsd right so let's dig in and start talking about process management in darwin right at the very fundamental level every process is a mock task right and every application is a process so at the very lowest level you have a mocktail a mock task is the unit of resource ownership as far as mock is concerned right every task owns threads it controls them it has virtual memory space and is managed through that mock task and it has a port namespace to collect all the IPC rights that are usable by that task right and so traditionally you can create tasks you can spend them and resume them and create new threads in them and get all kinds of information about them you can also one of the things people tend to do is create exception handlers for them right so that you can catch exceptions that happen in a task and process those and you can also get death a notification and be told when certain tasks that you have the handle to go away well that's a nice set of services right but typically you won't be able to use those directly I mean you actually can create a mock task all by itself in the system but you can't manage it right it's just this free-floating entity that no one else can see you snip you late so it's highly discouraged to ever create a mock task all by itself right instead you would tend to create a BST process and you do that through the standard BST api's you know v4 exact right create them and destroy them you'd go ahead and exit but the the BST process gives you these additional resources to go along with your task besides giving you the ability to manage them and name them right they give you the signal handlers they give you file descriptors they give you a whole collection of resources and what happens is when you when you have a bsd process right and you go look at the mock tasks KPIs that are available right a whole bunch of them go away you if you try to terminate a mock task that actually is part of a bsd process that'll just return you an error because the bsd part of the system doesn't have a chance to clean up and do the management that it would do right and so we don't allow that to happen of similarly creating new ones right we don't allow you to do that or we prefer you not do that right everything else is risky you can go ahead and create exception handlers you can go ahead and get info on the process itself or the task itself or get a list of threads or control threads create threads right but you shouldn't do anything else with the task right but again a lot of you will not be programming BSD processes you're actually going to be programming applications out at the higher level right either carbon cocoa Java whatever right and they add additional set of resources an additional set of API is for managing them actually many sets of API is for managing it one of the things that happens when you create those higher-level applications is they all talk to a common process management service that's a part of the core service core services in the system and it does all of the management for you and so you tend that's how you get things that pop up in actually right when you're looking at the tools that are available at that level right you have the doc and you have forced quit and all those things CPS the core process service is the thing that lets you manage processes and the larger applications all register with that our process viewer will actually let you view and inter SPECT just be of any bsd process in the system the same with top and PS and if you really want to see what's going on down at the the lower levels right you can use z print which is a tool that talks to the kernels zone management system and will basically print out statistics on how many of every kind of resource that the kernel has and in those list is all of the mock services and the mock resources that are available so you'll see how many mocked asks how many mock threads are being managed as well and so you can actually see and inspect some of the mock level resources with that tool so this is how you manage processes and handle exceptions and all of that is all at this level one of the things you have to be very careful about is although BSD processes have limits on the number of threat or the number open files and a lot of the other resources that are available to you one of the things that's not implemented in the kernel that shipped was ten point oh right is any ability to limit the resource allocations at the MOC level so any thread can go ahead and allocate these resources right and we don't have any limits on the amount of those resources you can go ahead and allocate and so if you have a runaway process right that's just leaking a port or leaking some kernel resource over and over and over and over again right over time the application may die that's certainly one outcome that might might come from this but another outcome from that particular problem is that it may actually just lock up the system and eventually panic the system because you've ran out of kernel resources in order to provide that so what you have to do is even though you're writing a carbon application or a cocoa application you need to take some of these tools top and PS in this case top if you were looking for leaks right and just watch your application running and if you happen to see something leaking away you need to address that okay so within a process you actually you obviously have threads all right and at the lowest level you have a mock thread mock does all the scheduling in the system some mock threads are the primary threading resource in the system one really interesting thing about mock threads it confuses a lot of people is that they actually have no resources other than scheduling attributes attributes and a register state that's it that is what a mock thread is right everything else you think about a thread stacks and per thread data and things like that mock doesn't know anything about those right it's all expected to be wrapped by some higher-level service and again at the mock level and an interesting thing is you can actually you know register for exception handling and death notification at the thread level and those kind of api's still are usable even when you look got it in the context of a BST threat or a pthread POSIX threads are the thing that provides the resources at the user level for a threat they provide the stack for a thread they provide the thread specific data implementation all right and those are the api's you can use to create them and manage them alright but again you may or may not just be stopping at a bsd process right you may be writing a carbon or a cocoa application and in those cases right you tend to not write to P threads you're gonna write to create a ns thread inside of cocoa or you're gonna create an MP task in a carbon application well those are BSD they are P threads right each and every one of those is a P thread each one of each and every one of those is a mock thread right and so you can have the breadth of services available to from each of those layers again at the thread level if you tried to destroy a mock thread right out from underneath of a P thread you can do it your applications free to do that it can do that to its own threads you're going to leave the P thread code implementation and alert right and so you better not do that but you could write and one nice thing about P threads the way the higher-level application services threading services wrap around the P thread level is that almost everything you can do to a P thread you can do from those on those higher level services and they tend to work well with each other right and so well how do I view threads in my system how do I tune for it how do I take care of the threading in my system and here's some tools you can do a thread viewer if anyone was at the performance tools meeting session yesterday you saw them going and actually showing thread viewer as an application that they were debugging during that process well they at the end of that meeting they the end of that session they decided that they were going to release that thread viewer to people as soon as possible so that's going to be a really nice application for viewing threads in the system in a graphical way and higher level because up until that point well you could sample threads with the sample app but that's kind of not something you would do ongoing and just watch your application go it's typically you've noticed a problem right and you would fire up sampler and go up and do what you needed to do right and top and PS I know I've had top running on the side of my system forever right but it's it's a lot it's like drinking from a firehose that's a lot of information it doesn't give you a graphical bang there's something going on there that I really need to worry about some of the tips well in Mac OS 10 we promote people to lazy in it as much as possible in their system right if you have a framework or anything else in your system you really want to delay initializing it one of the problems with the big bounces the bounce marks when you're launching an application intent is that a lot of the code brought over from nine basically had this model initialize everything once upfront right as much as you can and then will use it later right almost for free well in 10 what you're doing is initializing it all up what upfront once each time each application launches right and so one of the services you can use to get around that problem is this pthread ones facility which basically at the front of each major access point into your service right you can put a P thread once call the initialization routine at the front of that right and the P threads code will guarantee that the very first time you call one of your functions that has this in it it'll go call the initialization routine but it won't ever allow it to be called again from that code so that way you can delay your initialization until the very first time you're called now also a lot of people like to create their own debuggers or their own debugging environment and so they tend to want to get the exceptions from an application as it's running filter them through their own set of interfaces right and decide whether or not to let the system see rest of them later and so you can catch exceptions at any one of three places in mock right you can catch exceptions at the thread level at the tasks level and you can actually catch them at the the widest level the host level all right BSD tends to hook itself at the host level and so you know when a processor thread runs along and executes invalid instruction it's gone is send an exception down this chain it's gonna first send the exception message out to the thread level handler the thread lilifer thread level handler says he handled it then fine we'll just let the thread continue and we'll we'll go on from there if he didn't then you were gonna send it on to the next level right to the process level the task level and there's another handler sitting there if there is one then we'll send it to him and then same thing down below well BSD tends to be at the task level you're gonna see debuggers like gdb and things like that are gonna be sitting at the task level so bsts at the host gdb is at the task right and if you want to be able to intercept and get in there and do something on your own then you would tend to do it at the thread level okay so now that we have threads we obviously have to schedule them right and how do we schedule them well this has been somewhat of a mystery inside of Mac os10 there's obviously something going on with this banding you can see different threads being assigned different priorities but we have we've been messing with this tuning it and so we've been kind of adverse to putting out exactly what the banding is that we have in the system but now that you're trying to write real applications right you're gonna need to know alright some of you are writing multimedia applications and you really need to know how to get to be a fixed priority process how to how to set your priority well these are actually the bands that we have at the very highest so we have a range from 0 to 127 the very highest level are what we call time constraint threads right and so any thread that's registered as a time constraint thread and you don't have to be privileged to say you you want a time constraint thread right they will run up in that highest band somewhere and we that we won't tell you right but it's based on the time constraints that you provide and then we marry that with a bunch of other information and decide what priority you actually get within that band right but they tend to run at a fixed priority in that band so they'll just run run run run run run run if they have things to do and instance there are much higher band than most other applications obviously we're going to schedule those first we're also going to preemptively schedule those and so even if something else lowers running along in the kernel doing your kernel service if one of these comes along we're going to schedule it right well that leads into a concern obviously is that if any application can do this and can set one of these threads up really high then obviously any application can kill the system and there's no way you'd get it back it just runs up there forever and ever well we actually have limits to what can happen in a time constraint thread and so if you're running for too long in a time constraint thread then you get bumped back into the normal application band for a while and then if you settle down then we'll put you back into the time constraint band if you don't ever settle down then you just stay down there in the in the normal application ban okay and actually when you're in the application in the time constraint bin you're actually scheduled above the kernel threads above i/o threads so your your stuff will happen before will handle disk activity right it will be the first thing that kernel will go and run and then below the kernel in IO is is the core services threads things like the the GUI managers right so if you're running a time constraint thread and it's just chewing away guess what you know you you might even have trouble moving that Mouse around you might have trouble selecting that application to kill it right if it runs away that's why if it's run away it will get bumped down so that the core service threads have a chance to run and go ahead and get you for the rest of the threads you tend they tend to be grouped into two categories its GUI based threads and regular kind of background activity regular BSD process kind of threads right and the GUI ones tend to be a little bit higher in the bands then the the default ones but all of these threads are priority adjusted so as they run and take time they tend to start at their base and work their way down as they consume CPU under contention so if they're consuming CPU and nobody else is contending for the CPU they're fine they'll just stay stay stay stay stay as soon as they start contending for the CPU with other threads and other things once around they get nicked a little bit each time this happens right until those other threads get a chance to run right and then as a few Quantum's expire and they've been nicked then they drift back up and drift down so every thread tends to balance itself in this group and that's the standard policy in the system is to time share and adjust one of the things you can do in that category is assign precedence to your threads so if I have two priority two normal application threads right but I always want this one to have precedence over this one within my application then you can use the precedence policy setting this is given ordering to those and like I said we have we can take those threads and schedule them fully preemptively both kernel end user so we have a fully pre-emptive kernel if you're a time constraint thread you will interrupt things that right out of the kernel and we'll switch to you immediately right and we can obviously balance those across multiple CPUs all right when you're at the bsd process level well you have a few more things that come out for you you have the ability to set nice and if you've noticed in Mac OS 10 that actually doesn't do anything but the later versions that soon you will see a version that has that fixed right at the P thread level you can set your own scheduling attributes all right those will feed into the precedents into the timeshare in Lincoln and standard policy constraints and outlet the higher-level right you have management going on even beyond what this the mock level manages so if you're writing cooperative threads where you have deferred threads inside of your carbon application carbon is actually getting involved there and trying to make sure that those things run even though they're each a mock thread he's trying to make sure they run in the right order again you know some of the standard tools to look at things but the big tip here is don't use the old api's for setting things as round-robin or time share that are still available in the mach kernel you have use the new get policy set policy ap is that take the precedence and the time constraint all right so now that we've got scheduling and able to run let's see what we can do with anything outside of ourselves right and for that we need to access files typically right inside of the file management system of the whole kernel mock tasks actually has no concept of file right so you would think that mock is really not involved in this discussion but that's not true every file in the system really is managed and controlled the cache for the data that that application is managed and controlled by mock through what's called vm objects so mock manages the cache in the system the vm page cache and all of our filesystem activity right goes through the vm page cache to do what it needs to do so as you're reading from files reading files off a desk those files are stored in the regular vm cache right we don't have a file system cache and a vm cache for things that are you know applications that are mapped into your program we have one cache read read read read read it all goes into one pile right and it pushes things off the end of the pile right and again at the higher level those are wrapped yet again by different handles out at the application level one interesting that happens the interesting thing that happens there is that bsd is this basically a synchronous file access system right and a lot of the carbon applications are using a synchronous file i/o well how that works is that the actual carbon library in the system will go ahead and create worker threads that will issue the synchronous bsd calls for you right and manage sending you the asynchronous response later on so if you open files asynchronously in carbon right and you start at you start doing asynchronous reads in carbon or asynchronous writes don't be surprised when you go look you know with the tools and see there's another thread in my application that I have no can I didn't create right and it's created for you by that higher level right some really good tools to tune your use of files right is FS usage it's a tool that will basically as you're accessing a file it will spew out what's going on every access every read/write open/close either by a particular application or by any application overall and so you can get a basically a real-time view of everything that's going on file activity wise also there's another tool LSO F another command-line tool both of these are command line and it'll basically list every open file in the system right and who has it open what file descriptor number it is within that process it's a very useful tool alright big tip because we have this one cache right that handles all mapped files all your libraries all your frameworks all your executables and it's also the cache where you handle you know all the reading of files reading and writing a files if you happen to be reading something once and only once right spewing in a big image file or something like that that you're gonna process once right you don't need that file in the cache anymore you've got it in your application right having a copy of it in your application and having the original one in the cache just means we are taking up double the space in BM at least temporarily for that data so whenever you can use the no cash options right at the carbon level you have no cash reads and writes at the bsd level we actually have enough control that you can specify to say these are no cash operations ya really need to use the no cash operations alright otherwise as you run through memory write with big files you can push really important pieces of the system like the system framework and everything that you use and your own code right out of memory one thing that also gets people every once in a while is that while you typically were able to open in a carbon application as many files as you wanted until you hit the system limit in bsd there's a soft limit for the number of open per process and that's 256 right and so as you open ffs wraps inside of Carbon applications right you may end up running into this limit typically it's a bug right typically it's because you forget them to close them right and you just open open open open or open and eventually you'll hit the 256 limit we basically you have that limit now you can change it with a assist control or sorry yeah there's an API at the bsd level to basically up the limit for you right the same thing can happen at a system-wide level we have a system-wide level of number of V nodes which are the open file descriptors up there the open file handles right and those are you know there's a system-wide limit determined that boot time based on the amount of memory in the system and essentially you know some other tunable parameters well you can tune those up as well with us as control okay now we have files when we talked a little bit about VM right but we need to talk about the rest of what happens with VM right the mach vm pretty much controls the virtual memory in all of Mac OS 10 BSD provides some wrapper services to that but it's mostly managed by mock right mock provides the protected address spaces that Mac os10 you know is promoted here we have protected address spaces right one nice thing about the way mock does it is you have basically extreme flexibility and how you want to assemble an address space right you can put stuff here there everywhere it's really wonderful when you're trying to emulate an old system well guess what that's exactly what we're trying to do it's one of the key benefits of using mock VM is if you don't put if stuff had to be up there you can put it up there okay it also provides control sharing of resources so you can map things in exclusively into one application you can map them in copy-on-write into one but read right into the other so you can write into your piece of memory and the other guy can see it I can't modify it right or you can map things in readwrite into both all right so it's a really flexible way of putting systems together right and what does it look like well we showed in the picture before we showed a VM object and we showed cache pages sitting off of it and we showed this thing called a V node well the V node from the mock view of things is just an abstract memory manager it doesn't understand what that is all right it just has a protocol to talk to it and anybody can be one of those right and provide services and as long as you do will do the right thing well here you have to address faces each one of which has some portion of an object mapped in in this case they tend to have they have the same object mapped in the same part of the same object but they haven't mapped at two different addresses ones up at zero and the other ones somewhere down inside right and so you're running along and all of a sudden one of the guys takes a fault because the page isn't existing all right so we send a message basically not send a message but the the address space queries the virtual memory object and says do I have this page cache well guess what no I don't have this page cache so let me put a placeholder in case somebody else comes along and tries to do the same thing I won't do this again right which is sending a request to the memory object and the memory object sends back a data page and then we make that data page available in the application it's an L of a sudden you can go on and run but look what happened over in the other address space the guy with the same area mapped in but in a different part of his address space well we have the page cache now he doesn't have the page available to him right and if you had 250 objects that these guys share in common each one would have to have 250 entries pointing at you know each of the individual objects well if you're absolutely sure that you're going to have a whole bunch of them objects that are in common between two applications you can set up what's called a shared region which basically is a recursive address space right you can have an address space entry that points at another address space for any portion of it all right and we tend to use this in our system and I'll show you what for in a second right but we have two of them that we put into place one that tends to be sitting it's seven bazillion and the other one that's sitting at a bazillion right one is directly mapped shared by each of the applications and another is mapped copy-on-write by each of the applications so let's get rid of that copy-on-write one because it's a little confusing right for the moment right and what's backing that that shared address space well the same stuff that was backing the other address space right a reference to a memory object which has some cache pages associated with it and a reference off to some manager that knows how to fill in the data that it doesn't already have cached so now you come along and take a fault on that address right it queries the the shared address space and the shared address space then doesn't have the page either so it basic query is the object itself and we gotten up we don't have it so let's put a placeholder in place and we put the placeholder in the shared region well guess what because it's truly shared by the other guys the placeholder actually shows up in everybody at the same time right we sent the request on to the pager when he sends the data back wham the data shows up in every address space at the same time what do we use that for well if you take a dump of a typical mop Co application this is the layout you're gonna see right down it zero we tend to have a guard page all right that'll catch zero faults you know zero references and raise an exception for you if you don't like that idea you can go ahead and put another page there it's fine just replace that but that's the typical behavior right starting on the first page on up to the first gigabyte is typically your application where the application itself is mapped where the heaps and stuff tend to come right but heaps can be there and they can be you can fill up basically any of the space any of the holes in here with memory that you like so if you have a heat manager and like ours the basis says get me hunks right and then I'll subdivide them right once you run out of space between the application and one gig if you have more than that in heaps it'll go and find spots basically the first fit for another chunk going on up the line but if you notice it's seven and eight bazillion respectively right there's a read-only section and a copy-on-write section well this is where all the frameworks tend to fall right that your applications use so we have 70 some-odd frameworks that are a standard part of Mac OS 10 right if we had to map those into each application separately right and manage them separately and relocate them separately right we'd be going through a lot of extra overhead right as each application launched so what we do instead is have a shared region that points off at all the shared text of an application we relocate it once if it has to be relocated but typically it doesn't because a lot of our system is pre bound our libraries and they sit and point off in that one area right and then we map the data part of that you know add another one or yeah 256 Meg off of that right copy-on-write into each application so as each one takes a rights particular parts of the data they get their own copy by doing this at 256 Meg offsets we actually get to take advantage of something that happens in the powerpc right which is that you can actually truly share TLB entries and everything like that on a 256 Meg boundary with people so at the 7 bazillion where all the frameworks are alright we're actually sharing TLB entries and everything between every application right unless that application goes in and replaces the library or overloads the library or says you know use a different library for me right then we have to relocate the other parts of that collection of libraries at which point you get your own private copy and it behaves like a traditional old-fashioned application right so how do you go ahead and debug a you know the VM services you have well one of the best benefi will to you if you are watching at the tool session yesterday is malloc debug it's a wonderful thing to see you know individual parts of your heap being leaked leaked away and whether or not you're actually using them anymore and whether they could be reclaimed right but that doesn't catch memory allocations that happen outside of the heap manager right and there's lots of reasons why memory would be allocated outside the heap manager and directly fill up your address space right and there's this tool called VM map which will actually just give you a dump of all the it's a command-line tool sorry that will give you a dump of all the mappings in your system in your application and you can find the ones that you don't seem to realize you don't remember having right and start investigating those and what you'll tend to find is that something sent you a piece of memory and you just forgot about it all right something in the system sent it to you out of line in a message or some other way or you allocated a hunk directly with VM allocate right instead of using the the malloc tools and you just let it dangle all right and that will show you those you can also see those in top right so you the police you go first is top and to watch your application running if you see the number of memory entries going up and up and up and up and up right you're probably forgetting to do it's something that you really needed to deallocate all right one of the things that happens is when you do one of those VM allocates right they tend to start at zero and find the first fit right so when you're looking through your address map and you see a bunch of entries up by zero right these are probably pieces of memory that were allocated with the Amalekite and you might want to look at those another really important tip goes along with the no cash option is if you map things into your address space or you malloc a big hunk of memory right or you allocate it and you use it and now you're done with it but you know you really don't want to keep allocating it and deallocating it because maybe it's expensive well you want to kill it all right kill it out of the cache and there's a couple of ways you can do that there's an EM sync option at the POSIX level that let you kill pages there's another one at the Mach level called vmm sync they're really useable interchangeably depends on what API set you want to stick to but you need to kill them okay so we talked about all these things we've got you know tasks and threads and address spaces and they're all protected but when you have a protected address space in a protected environment you need to communicate somehow and so that brings us to the IPC services right and again Mach plays a big part in the IPC services of Mac OS 10 not so much in what happens at the BSD level so in a BSD process it might not be that important but in Mac OS 10 in general it actually becomes very important so an address sorry the basic idea of IPC service in Mac OS 10 is mock IPC mock IPC manages writes in port namespaces associated with each task you have rights to ports it's kind of like an open file descriptor inside of BSD but instead it's - a communications channel a small one called a mock port so here I have a mach port in the second task that gives me the right to send the message to the first task what's really nice about Mac o ten or about Mach IPC is that if you have memory and you have other port rights right you can collect those together and send them in messages over to the other task and so you can do really flexible communication so I've got a piece of memory in my address space in task 2 and I've got another port right in task 2 one that I own the receive write for and what I do is I build a little message that basically contains you know some general description of what I'm sending but it also contains a reference to each of these things right and I send it over to the test to that port that I have right and when it's received over in task one guess what now he has new virtual memory and he has new port rights right and so he can use the port right I just get gave him to send the message back to me saying I'm done what I'm doing all right and so all the RPC in the interaction that goes on inside of Mac OS 10 or a large portion of it happens via this mechanism when you want to open a window write that in a GUI application well the frameworks inside of your application talked to the core graphic server the window server by sending a message a mock message over there saying we need to do something and what they do is they arrange to have a piece of shared memory in common to do most of the communication but then they are constantly sending messages back and forth to each other about what the state of that is so again you have this inside of each task you have a collection of these ports right and they can represent you know just a basic message queue there's also variants there like semaphores lock sets right there handles to things that the kernel implements and they can be collected in sets and that collection in sets is really important because if you look inside of an application that GUI application in Mac OS 10 you gotta see at least one of these CF run loop things right which is the basic primitive of the event mechanism inside of Mac OS 10 and a CF run loop is actually just a wrapper around a mock port set right or a collection of mach port set so you may have many port sets and the CF run loops own some of them and put some rights and portraits into them and each of those port rights represents thing that can drive events a source of events that your application may need to deal with so he's already got a bunch in this support set but you know as time goes on he has more and more and more and what what you realize is while you're talking to a lot of things inside of Mac os10 V ports every once in a while you're talking to her traditional BSD application or you're talking to a traditional you know who knows right there's lots of other ways you can communicate with things but you need to somehow you know most applications feed that back into the run loop so that your application can see the events driven by these other sources well you can't be sitting at a single weight right when you do a CF run loop wait all right it sits on a port set waiting for a message right if that isn't coming in via port set that thread isn't going to see it or through a port it's not gonna see it so that thread connect that run loop can actually create worker threads for the kinds of IPC that he doesn't that is in port based receives the in this case off of a socket receives the message off a socket or the data office socket and tickles another port inside the port set to wake the run loop up some of those other sources that you can get things on right at the bsd level you have sockets and POSIX semaphores right and you have P thread synchronizers right now the P thread synchronizers our intro task only but as time goes on they'll become you know inter task as POSIX says they're allowed to be and then they're gonna have to feed into this mechanism as well if you want to be able to receive them in a single place right and then what happens at the outer level again is you have a port set that's wrapped by a run loop that becomes the foundation of your event queue inside of your application and so well as you're watching your applications your main thread is going to be calling you know wait next event let's hopefully not maybe it's you hopefully it's using carbon events but if it is calling wait next event that's going to be calling CF run loop we'll see if run loop actually built up one of these port sets of all the things that can drive events into it right and then that's calling Mach message trap typically Mach message overwrite trap doing a receive waiting for stuff to come in right so you're gonna see that over and over and over and over again in each of your applications again when you're looking in sampler you're gonna see that kind of thing you're also gonna see it in SE usage and you're gonna if you run se usage at the bottom it tends to list all the threads and what they're doing what they're currently waiting on all right and you're gonna see Mach message over I trap Mach message over I trap mic message overwrite trap message over a trap right they're all coming in on run loops of some sort or another or directly receiving on a Mach message right ports represent almost everything in my core or in Mac os10 a large portion of things so like again if you have a window open the handle for the window is a port so when you look at the cg debug stuff phrase has a list down the side of the things the ports that it has open to represent each one of those windows right and if you're tempted to use the the IPC directly the mock IPC we prefer you not there's a tool called mig it's mock interface generator and it's basically an ideal compiler that wraps around mock messaging and you can specify routines that go both directions or one-way messages and it generates wrapper routines that generate those messages for you and receive those messages for you so you don't have to understand and manipulate the low-level messaging it's just a nice convenience okay so now we have the ability to communicate but we're supposed to have a secure system here all right how do we do that well again a lot comes back to those ports you have ports are restricted you can't just invent a port name inside of mock and say I want to send a message to that port right you have to somebody has to give you that or ascend right to that port in the first place now some of them are registered globally we can just look them up and get them so you can send some common service a message saying I want to do something and it'll respond to that all right but in a lot of ways a lot of cases they aren't registered globally so maybe you'll talk to a service through a global port and it will send you back a port that only you can talk to it to directly manipulate your windows that's why inside of the Windows Server communication right you get a new port per window because it only wants you and only you to be able to manipulate that window and the port right mechanism allows that to happen without him doing anything on his side I received a message on that port it must be him or somebody he delegated to send this message I'll do it right so they're pre-authorized and in fact Mac OS I mean MOC part of Mac OS 10 has no authorization facility at all right it basically says if you've got that port and you send a message on it we'll do what that message says to do right and those messages those ports represent things inside of the kernel as well so if you have a task or a thread or any of those other kernel resources they're represented by unique ports you get a hold of one of those ports a thread port you send a message to it saying terminate guess what it'll terminate right so you got to be careful about sending your ports out but it's also a really nice mechanism to say you know we're not going to just say that ap eyes are available and usable by the application themselves like threading ap eyes if that application wants to send its thread port over to a friend that friend can issue all the threading api's itself directly on that port and we'll treat it at the kernel level just like the application had done it itself the same thing with managing the port space the port space is represented by the task port and so getting things in and out of your own port space is done with that same thing the only nod to authorization that the the Mach level services provide is that each message that sent is sent with a tag some kind of security tag on it that basically says I don't know what this is but somebody said five was associated with the guy who sent this message so I'm gonna send five along right well what happens is the BSD layer is the guy who says what five means right he provides the identification and authorization in the system identification is you IDs inside the BSD world right user IDs you have user IDs and effective user IDs and your group IDs an effective group IDs and you have you know correct collection of groups that you're allowed to be in right and whatever you BSD says this task has a security token is what gets sent along well BSD is also the guy who maintains permissions at the file level makes sense because he's the guy who implements the file systems at his level and so all the authorization to gain access to files is done by the BSD layer right and he does somewhat similar to what MOC does right once he gains has given access to something through the file system he has a file descriptor which is basically the access point the restricted access point and permissions are associated with that file descriptor so it's it's pre-authorized pre cached authorizations right but BSD semantics and pot and mock semantics alone aren't enough for Mac os10 in general right you have applications that want to run as a general user a regular old user that need to do privileged things right sometimes we have a privilege server that's just sitting over there waiting to do that thing for you right and other times we have a server that is privileged to do specific things and will authorize you time each time to to do that one particular thing through the new authorization API that happens as a core service API right also at that level you have keychains and key chain management and all that stuff is done up above the basic primitives of the BSD file and UID stuff and the MA sport stuff all right again FS usage is nice because it shows you what kind of accesses you're doing to a file LS Oh F will tell you what kind of access is you have to a file VM map will tell you what kind of permissions you have on certain memory so if you've read write or rewrite copy-on-write so that when you actually touch the thing you get a unique copy instead of being able to write to the actual main store so you can get a feel for what's going on in the system that way one thing to do is take a nod from the Mach part and the BSD part which is to cash authorizations right if you have to do some of your own work well yes you could set up a server that receives messages and just constantly looks at the the security token on the bottom of a message and says well am I allowed to take this from this guy because he says he's five right do I allow five to do this or do I say no right that's kind of awkward to keep doing that over and over and over again right so you would prefer to establish a unique connection with each of your clients in that situation and receive only and pass out the send right on the other side only to that one guy and then every time a message comes in on that right you allow him to go ahead and access it all right so those were the basic services inside the kernel right where can you get more information about how this stuff all really works because this was far too much and far too quick to get to much of anything totally useful out of it well there's a good resource right on the developer CD and if you've installed that now it's right on the disk of your system and most people don't even realize it's there right under the developer section there's a documentation section under that there's a kernel section right and there's descriptions there's a basic description of the kernel services again some more details about how they're managed what the api's are and especially on this particular part there's a reference to something called the OSF documentation well our mock kernel is the OSF mach kernel so if you clink click through that link you're going to go ahead and find the documentation for the mocks api's that we have in our system they're not 100% accurate they're quite a few years old and we've made some changes internally but they're pretty good and it gives you a really good idea of how the mock part of the system works there's obviously the Darwin open source pages you can go to those all right and the Mac os10 home page and our tech writers have renamed the book on me it's the design implementation of the four for BSD operating system by mcusic it's great for the BSD side of things right where can you learn more here today sorry but for those of people who are watching via the DVD later on you can go look up these sessions the performance tool session was really good it shows you how to see the effects of all of these interactions inside of an application that you're writing the same thing with the debugging stuff so when you get your CD later go look at the debugging and the performance stuff they're really important you just saw the leveraging the BSD more than likely if you were here and in a few minutes you'll get to do feedback [Applause] you