|
From: | Campbell Barton |
Subject: | Re: [PATCH] support for accessing CPU/core count (processor-count) |
Date: | Mon, 11 Oct 2021 09:58:05 +1100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 |
On 10/11/21 06:50, Arthur Miller wrote:
Stefan Monnier <monnier@iro.umontreal.ca> writes:We seem to be talking past each other. I don't see why would want this as a C primitive.There are typically 2 reasons to use C: - For speed - To use someone else's code which is easily available from C but not from ELisp.Of course, but I don't see any of those apply to this case :).
The Elisp version of this function posted was incomplete by comparison in that it didn't support OpenBSD's ncpuonline feature or HPUX.
Also, this is not simply a call to an external process (executable-find "nproc") has some additional overhead.
I don't see this so much a case of ELisp vs C, more a case of OS-level API's being more appropriate than searching around for commands and parsing their output.
As I see nproc from core-utils is already doing suggested, and more than so, so it is just to call it :). https://github.com/coreutils/gnulib/blob/master/lib/nproc.c PS: it is not directly "a couple of lines" either as someone suggested :).
Right, it's quite involved, as mentioned in a previous reply, this seems more appropriate for detecting OS-level threads (not spawning new processes).
[Prev in Thread] | Current Thread | [Next in Thread] |