<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default">Hi David,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 12, 2020 at 8:28 PM David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Sun, Oct 11, 2020 at 11:15:09AM -0700, Eliot Miranda wrote:<br>
> Hi All,<br>
> <br>
>     I want to implement a number of processors query on MacOS & other<br>
> unices to complement the info provided by GetSystemInfo on Windows. The<br>
> natural way to do this on unices is to use sysconf (3), and of course this<br>
> points to the issue for which FFI pools are needed, the constant names for<br>
> sysconf such as _SC_NPROCESSORS_ONLN are defined, but their values are<br>
> implementation dependent.<br>
> <br>
> But before I go amd implement an FFI pool for this I thought I'd ask<br>
> a) anyone already done this?  Is it published anywhere?<br>
> b) how are we going to organize such pools so that people don't have to<br>
> reinvent the wheel?<br>
> c) should there be a pool to cover sysconf or to cover unistd.h?  (the<br>
> point here is that while the pool might start off small, it could grow and<br>
> grow and maybe unistd.h is too much surface to cover)<br>
> <br>
> thoughts, suggestions?<br>
<br>
Hi Eliot,<br>
<br>
At first glance, it looks to me like the hard part of the problem is to<br>
know what sysconf names are available to be queried on any given platform<br>
at runtime.  If you know that, or if you are only interested in a limited<br>
number of well-known parameters (which seems likely), then it might be<br>
simplest to just implement the sysconf(3) call either as an FFI call or<br>
a call through the OSProcess plugin.<br></blockquote><div><br></div><div class="gmail_default">Well, I *am* implementing it as an FFI call in Terf.  The issue is deriving the right integer values for the particular symbolic names, because these vary across implementations. And that's what FFIPools are designed to manage.</div><div class="gmail_default">Right now I don't have the FFIPool so I've hard-wired the constant:</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default"><div class="gmail_default" style="font-size:large"><font face="times new roman, serif">!CMacOSXPlatform methodsFor: 'accessing' stamp: 'eem 10/11/2020 17:53' prior: 47990341!</font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif">numberOfCPUs</font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif">        "Warning, warning, Will Robertson!!!! The sysconf method bakes in a decidedly implementation-specific name for the support library *and* bakes in a value for a symbolic constant.  Both of these are implementation dependent and subject to change.  That said..."</font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif">        ^self sysconf: 58</font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif"><br></font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif">        "CPlatform current numberOfCPUs"! !</font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif">!CMacOSXPlatform methodsFor: 'private' stamp: 'eem 10/11/2020 17:51'!</font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif">sysconf: systemInfo</font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif">        "Answer a value from sysconf(3)."</font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif">        <apicall: longlong 'sysconf' (long) module: '/usr/lib/system/libsystem_c.dylib'></font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif">        ^self externalCallFailed</font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif"><br></font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif">        " | scnprocsonline |</font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif">        scnprocsonline := 58.</font></div><div class="gmail_default" style="font-size:large"><font face="times new roman, serif">        self current sysconf: scnprocsonline"! !</font></div><div class="gmail_default" style="font-size:large"><font face="arial, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, sans-serif">There's much to be unhappy about in this code: libSystem.dylib is the abstract name, but one can't use it because the search facilities can't chain through the libraries that libSystem.B.dylib (ibSystem.dylib is a symbolic link) refers to.  So this could break in some future MacOS, whereas if libSystem.dylib did work, or if there was a symbolic name we could use that meant "the C library goddamnit", then it could be relied upon.  58 is meaningful only on MacOS, and presumably only since a particular version.  That's why we need an FFIPool to manage the cross-platform variations.  The type is longlong, which means we're not using a syntax that matches the declaration, and this will work only on 64-bits.  We can fix the FFI to interpret C names accoding to the playtform, but we have a serious backwards-compatibility problem in that all of the FFI definitions up til now have been written under this assumption.</font></div><div class="gmail_default"><font face="arial, sans-serif"><br></font></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">But I suspect that I am not answering the right question here. If I am<br>
off base, can you give an example of some of the parameters that you<br>
would want to be able to query?<br></blockquote><div><br></div><div class="gmail_default">First off Terf needs _SC_NUM_PROCESSORS_ONLN, which is notionally the number of processors online, but now answers the number of cores, which shows you how fast these ideas go stale (<span style="color:rgb(0,0,0);font-family:-webkit-standard">_SC_NUM_PROCESSORS_CONF is the number of </span><font face="arial, sans-serif"><span style="color:rgb(0,0,0)">processors configured ;-) )</span>.  Other ones that could be meaningful for applications include _SC_ARG_MAX (The maximum bytes of argument to execve(2)) _SC_CHILD_MAX (The maximum number of simultaneous processes per user id), _SC_OPEN_MAX (The maximum number of open files per user id), _SC_STREAM_MAX (The minimum maximum number of streams that a process may have open at any one time), _SC_PHYS_PAGES (The number of pages of physical memory).</font></div><div class="gmail_default"><br></div><div class="gmail_default">There are many others, quite a few I can't imagine ever being compelling.</div><div class="gmail_default"><br></div><div class="gmail_default">Now yes, one can imagine implementing a cross-platform abstraction for these but it's a lot of effort for little gain.  It;s easier just to suck it up and implement the FFI call.</div><div class="gmail_default"><br></div><div class="gmail_default">But I'm imagining these things will get used by the community and I don't want people to have to reinvent the wheel.  This kind of stuff doesn't belong in trunk, but it does belong somewhere where we can share and coevolve the facilities.</div><div class="gmail_default"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
Dave<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></div></div></div></div>