Hi David,

On Mon, Oct 12, 2020 at 8:28 PM David T. Lewis <lewis at mail.msen.com> wrote:

> On Sun, Oct 11, 2020 at 11:15:09AM -0700, Eliot Miranda wrote:
> > Hi All,
> >
> >     I want to implement a number of processors query on MacOS & other
> > unices to complement the info provided by GetSystemInfo on Windows. The
> > natural way to do this on unices is to use sysconf (3), and of course
> this
> > points to the issue for which FFI pools are needed, the constant names
> for
> > sysconf such as _SC_NPROCESSORS_ONLN are defined, but their values are
> > implementation dependent.
> >
> > But before I go amd implement an FFI pool for this I thought I'd ask
> > a) anyone already done this?  Is it published anywhere?
> > b) how are we going to organize such pools so that people don't have to
> > reinvent the wheel?
> > c) should there be a pool to cover sysconf or to cover unistd.h?  (the
> > point here is that while the pool might start off small, it could grow
> and
> > grow and maybe unistd.h is too much surface to cover)
> >
> > thoughts, suggestions?
>
> Hi Eliot,
>
> At first glance, it looks to me like the hard part of the problem is to
> know what sysconf names are available to be queried on any given platform
> at runtime.  If you know that, or if you are only interested in a limited
> number of well-known parameters (which seems likely), then it might be
> simplest to just implement the sysconf(3) call either as an FFI call or
> a call through the OSProcess plugin.
>

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.
Right now I don't have the FFIPool so I've hard-wired the constant:

!CMacOSXPlatform methodsFor: 'accessing' stamp: 'eem 10/11/2020 17:53'
prior: 47990341!
numberOfCPUs
        "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..."
        ^self sysconf: 58

        "CPlatform current numberOfCPUs"! !
!CMacOSXPlatform methodsFor: 'private' stamp: 'eem 10/11/2020 17:51'!
sysconf: systemInfo
        "Answer a value from sysconf(3)."
        <apicall: longlong 'sysconf' (long) module:
'/usr/lib/system/libsystem_c.dylib'>
        ^self externalCallFailed

        " | scnprocsonline |
        scnprocsonline := 58.
        self current sysconf: scnprocsonline"! !

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.

But I suspect that I am not answering the right question here. If I am
> off base, can you give an example of some of the parameters that you
> would want to be able to query?
>

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 (_SC_NUM_PROCESSORS_CONF is the
number of processors configured ;-) ).  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).

There are many others, quite a few I can't imagine ever being compelling.

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.

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.


> Thanks,
> Dave
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201013/93b5ba09/attachment.html>