4 ms·
Sure it means something. Both Windows[1] and OS X[2] have easy ways to do it, and the task list in the Linux kernel is just a linked list that could be easily a
by tcoppi 10y ago
Sure it means something. Both Windows[1] and OS X[2] have easy ways to do it, and the task list in the Linux kernel is just a linked list that could be easily atomically copied. Obviously a lot of the metadata associated with the processes couldn't be easily accessed in a consistent way, but the number of running processes, their pid, basic info like the command line and process image is totally knowable to the kernel at any given instant.
The fact that you can't get that info easily on Linux makes a lot of tools harder to write than they should be, and often give misleading/incorrect information.
1. https://msdn.microsoft.com/en-us/library/windows/desktop/ms686701(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
2. https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man3/sysctl.3.html https://developer.apple.com/legacy/library/documentation/Dar...
- jerf 10y agoAt least the Windows one is the function I wasn't willing to assert exists. However, it does not appear to have the "a lot of other stuff in that snapshot which is not [linearizable].". The resulting structs[1] are missing many things that ps may want to display in Linux, which you will have to fetch nonatomically. The OSX one, I don't know; I scanned over the docs and it went over my threshold for what I'm willing to poke through for a HN post. In other words, this is exactly what I left myself an out for, and I see nothing that contradicts what I said for the Windows case. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/ms684839(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
- tcoppi 10y agoI don't disagree that there is a lot of information you cannot include in such a snapshot, and neither the Windows or OS X equivalents(it's the KERN_PROC argument to sysctl btw) give you much detail beyond all pids(which you can get with a directory listing of /proc in linux, though this is not completely atomic either, even with getdents(2)!) and their cmd line/exe path. Those latter two are completely unavailable to get reliably with any method I know of on linux, and that results in some inconsistent and/or incomplete info for certain use cases, especially when combined with the fact that PIDs, though randomized, can be reused on linux.