Follow

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
Mastodon

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!