daniel02216's comments

That it changes cores only when the window becomes invisible is likely due to App Nap - check the energy tab in Activity Monitor.

https://developer.apple.com/library/archive/documentation/Pe...

https://developer.apple.com/library/archive/documentation/Pe...

It looks like roomkey.com doesn't seem to have any mobile apps, which makes it hard to say that it's more convenient to use when traveling than an aggregator that does have an app.

It's interesting to hear about your site though, perhaps I'll try it out next time I'm traveling.

EV_ONESHOT refers to the individual kevent registration, and is basically an automatic EV_DELETE on delivery of the event.

EPOLLEXCLUSIVE is acting at a different layer - in kevent terms it would cause only one of the registered kevents watching an object to be activated when the object is ready instead of all of the kevents watching for the same thing.

This is one reason why OS X enforces a hard page-zero on 64-bit programs - it is a hard error to map or allocate anything in the lowest 4 GB of memory, so programmers will immediately discover pointer truncation bugs when porting 32-bit code to 64-bit.

This is true - the compatibility boundary for OS X is at the link-against-libSystem layer. The actual interface between libSystem and the kernel is private to Apple and is not guaranteed to stay argument or ABI compatible. (this includes the syscall() function)

Several xnu syscalls are actually paired with a userspace wrapper function that does some extra stuff. Existing syscalls may even become wrapped in a subsequent release if needed.

And a bunch of those are using Wine, which requires mapping code at the zero page, so they're compiled with a special load command that allows them to map the zero page.

On Yosemite, 64-bit binaries aren't allowed to do this.

As of GCC 5, it has __builtin_add_overflow, __builtin_sub_overflow, __builtin_mul_overflow

https://gcc.gnu.org/gcc-5/changes.html

That's just the syscall for waiting for a semaphore to be signaled. Most likely the crash is due to the main thread waiting for too long on that semaphore - it's likely stuck waiting for a network request to complete, and the watchdog kicked in and killed it.

For vim at least you can put 'set shell=bash' in your .vimrc and it will use bash instead.

It's UIUC's license, which looks similar to BSD to me. They also have some MIT licensed code. http://llvm.org/docs/DeveloperPolicy.html#license