|Summary:||sys-apps/portage: could wrap compilers to avoid exponential job growth|
|Product:||Portage Development||Reporter:||Michał Górny <mgorny>|
|Component:||Conceptual/Abstract Ideas||Assignee:||Portage team <dev-portage>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Michał Górny 2020-09-22 14:01:06 UTC
Comment 1 Michał Górny 2020-09-22 16:29:57 UTC
Well, I see three options for implementing this. An obvious solution would be to use POSIX named semaphores. They have exactly the semantics we need and should be efficient. However, they do not release locks (post semaphores) if the process crashes, so we could end up having successive jobs permalocked. Adding a 'reaper' for this would probably make it more complex than the alternatives. A trivial option would be to use lockfiles. Basically, we create a lockfile for each allowed job and try to lock it non-blocking in a waiting loop. Its disadvantage is that it introduces arbitrary delays while waiting for a lock, and I don't see any good way that would avoid adding complexity while maintaining good locking speed and small CPU utilization. Finally, we could use a client-server layout, with the server being started on first emerge process and its clients requesting semaphore locks via UNIX socket. This has the advantage that we can use socket connections to release resources automatically but it might have more complexity than the other solutions.