Try running that analysis for iOS apps against the dyld shared cache or for Android apps against the Android system frameworks.
434 karma · joined January 14, 2013
Maybe it is useful outside of the browser context, e.g. in gRPC.
If you do this, you'd better make sure that you hotload the new version of B before you hotload the new version of A. Otherwise some process could end up trying to call B:bar through A:foo before the new B has finished loading.
If you rely on hotloading modules as your primary deploy mechanism, you will run into issues like this all the time. So it's not really clear to me that hotloading is a win for your typical stateless web service compared to just deploying a new binary and doing your standard zero-downtime deploy via forking.
It makes more sense when you realize that certain Erlang apps build up a huge amount of state in-memory. In those cases hotloading allows you to load new versions of the changed modules without having to take down the whole VM.
The main benefit was the ability to load and store Erlang terms natively, along with the fact that it's just a library. The fact that your compute is colocated with your storage lends itself to a different architecture than when you use, say, a stateless web service in front of a relational database.
(Edit: I realize now that I'm replying to a WA old-timer so I'd be curious to know what your assessment of mnesia is with the benefit of hindsight.)
And I happen to agree with it.
One example is the iPad Contacts app. Originally it was a simple list of contacts like you'd find in Outlook. This was changed to the "little address book" UI that looked like a leather-bound address book much later in the process because the original UI wasn't "fun" enough.
Just one simple example: run "sample <process>" (where <process> is any Cocoa application) on OS X. Pretty much every thread will have an event loop powered by CFRunLoop, and they'll all be stuck in mach_msg_trap waiting for an event to occur.
Also, pretty much any sort of semi-complicated IPC on OS X is done over Mach IPC (e.g. passing a large bitmap copy-on-write from one process to another). Take a look at the ipc directory in the Chromium source, for example.
Here is an example syllabus from Stanford's CS240: https://web.stanford.edu/class/cs240/old/sp2014/. You can see that this paper is listed, along with a paper that states the opposite opinion ("Why Events are a Bad Idea").
There was talk at some point of adding a single syscall that got all the PCs of all the threads at once to cut down on the overhead, but it looks like that still hasn't happened.
What's going on here is something like this:
1. objc_msgSend is Obj-C's method dispatcher, and it depends on method caches to make method lookup faster.
2. Sometimes the method caches become out of date. For instance, maybe the method cache filled up and the Obj-C runtime needs to allocate a larger method cache.
3. This old method cache has to be GC'd at some point, so it's added to a freelist.
4. This GC function (the "write" you're talking about) for these caches runs once the size of outdated method caches grows beyond a certain threshold (garbage_threshold in the code). So it shouldn't run too often. The GC function works by checking if any thread is currently within objc_msgSend. If no function is in objc_msgSend, then the runtime is sure that none of the method caches on the free list is in use.
5. It is definitely optimized for reads. The "read" in this case is literally a method dispatch so it happens all the time, and it's important for the read to be lock-free.
https://github.com/opensource-apple/objc4/blob/master/runtim...
Basically, issue a syscall that acquires the PC of all threads. When none of the PCs are in the critical section, then you can garbage collect old objects.
"The faculty on its part manifests its confidence in the honor of its students by refraining from proctoring examinations and from taking unusual and unreasonable precautions to prevent the forms of dishonesty mentioned above."
https://communitystandards.stanford.edu/student-conduct-proc...
A professor or grad student walks into the room every 30 minutes or so just to make sure everything looks okay. They otherwise sit outside the exam hall so you can ask them questions, ask to go the bathroom, etc. But it's up to the students to police each other and ultimately themselves.
There are definitely other universities in the US that have this policy, but I would say it's more the exception than the norm.
Apple's model uses a public/private key pair: the private key never leaves your server and Apple doesn't know it. Apple only knows the public key, in the form of a cert. Apple actually writes about the trust model in the docs: https://developer.apple.com/library/ios/documentation/Networ....
Google's model uses a shared secret (the API key) that both the client and server know.
Having worked with both systems, I prefer the ease of the shared secret model, but each system uses a fundamentally different security model.