btw on the subject of “should I use NSOperationQueue or libdispatch”, since it came up, my concrete recommendation is: you should really strongly consider not writing async/concurrent code.

I know this sounds weird in 2018, but the cost in complexity *and* performance is high.

There are absolutely cases it’s worthwhile, but empirically the cutoff point leans more single threaded than most programmers think it does.

I dug up a comment I wrote last April to warn future maintainers of the daemon I wrote not to reintroduce parallel handling of request contents. Ideally, we would multiplex all requests onto one priority-ordered queue too for a nice perf win, but for arcane reasons it’s unsafe.

@Catfish_Man I tend to agree. Back in the day, we did not have threads and the scheduling entity was a process, and you only could do things through forks, and you could not take page faults above priority zero

@jeffmc oh interesting. That latter bit I hadn't heard, that's a fascinating restriction!

@Catfish_Man which meant if you took an interrupt in a device driver, scheduled a fork to run processing of the interrupt, all the code you ran had to be running in non-paged pool, because of that restriction.

@Catfish_Man in my experience, i’ve seen people drift to these things as a matter of processing many of the same/similar type of request when the concurrency component is not needed — wondering if there could be a new data structure for the purpose of uniformly processing items without the extra complexity

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!