News for hackers. Stuff that matters.

A comment on The Unscalable, Deadlock-Prone, Thread Pool. Parent comment

Re:The Unscalable, Deadlock-Prone, Thread Pool by 0db532a0 on Wednesday February 27, 2019 @09:28AM (#19263398)
That’s quite an interesting problem. The mlock [1] system call allows you to lock chosen virtual memory into RAM. What about using that in combination with a memory pool which you manage yourself?

[1] https://developer.apple.com/library/archive/documentation/Sy...

[ Parent | on HN ]
Re:The Unscalable, Deadlock-Prone, Thread Pool by magnetic on Wednesday February 27, 2019 @10:53AM (#19263961)
If I had all places where memory is allocated under my "jurisdiction", I think this would be a very applicable solution.

Unfortunately when calling APIs to process images, some opaque code that you don't see ends up doing allocations on your behalf, and you can rarely pass your own pool to allocate memory from.

[ Parent | on HN ]
Re:The Unscalable, Deadlock-Prone, Thread Pool by 0db532a0 on Wednesday February 27, 2019 @12:56PM (#19265305)
For the record, mlockall on Linux can lock all future allocations, including those made by shared libraries. You don’t need to manage a memory pool yourself.

https://linux.die.net/man/2/mlock

[ Parent | on HN ]
Re:The Unscalable, Deadlock-Prone, Thread Pool by magnetic on Wednesday February 27, 2019 @01:46PM (#19265802)
That's very cool!

It looks like that API doesn't exist on macOS, though... :-(

[ Parent | on HN ]
Re:The Unscalable, Deadlock-Prone, Thread Pool by 0db532a0 on Wednesday February 27, 2019 @12:53PM (#19265270)
That’s true. I didn’t consider that. I’d be interested love to see a solution to it though. Maybe there’s some sort of OS-level solution, like how you can set the priority of processes.
[ Parent | on HN ]