<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi Eliot!<div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">I should push thoguh and sdo a sysconf pool to learn how the current </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">system really works :-)</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">This is so exciting!! ^__^</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div><blockquote class='history_container' type='cite' style='border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;'>
<p style='color: #AAAAAA; margin-top: 10px;'>Am 17.10.2020 00:24:11 schrieb Eliot Miranda <eliot.miranda@gmail.com>:</p><div style='font-family:Arial,Helvetica,sans-serif'> <br>Hi David,<br><br><br>> On Oct 16, 2020, at 2:47 PM, David T. Lewis <lewis@mail.msen.com> wrote:<br>><br>> Hi Eliot,<br>><br>> Replying back on vm-dev.<br>><br>> Indeed I see the problem now, thanks.<br>><br>> The closest that I can come to a useful suggestion is to write a<br>> little C program to print out the index values of interest for a<br>> given platform, then read that into the image to build the pool.<br>> The index values are supposed to be opaque but I doubt that they<br>> would change much in practice.<br><br>This is what an ExternalPool does *automatically*. One creates a pool<br>containing a set of named variables, adds metadata to the pool, and<br>then when the pool needs to initialize or change, it generates the C<br>program automatically, runs it, reaps the values, and updates class<br>side code to initialize the constants for specific platforms. When it<br>is run on a different platform it generates the program for that<br>platform, etc. The management problem therefore is how to manage the<br>executable programs because these are needed if one wants to deploy on<br>a specific platform.<br><br>I came up with the idea many years ago at ParcPlace when the problem<br>first surfaced (that different platforms, though they may use the same<br>names for symbolic constants, abstract types, etc, but don't use the<br>same values, concrete types, etc). Monty write the implementation.<br>Marcel has shepherded it into source.squeak.org/FFI. Marcel has<br>written an excellent and comprehensive class comment for ExternalPool.<br>I urge that everyone interested in deployment using FFIs read it ASAP.<br>That goes for me too, because things have moved on with the<br>implementation. There's no need to manage external C programs;<br>there's a need to merge the definition code that is automatically<br>generated when run on different platforms.<br><br>I should push thoguh and sdo a sysconf pool to learn how the current<br>system really works :-)<br><br>><br>> I am looking only at a Linux system as I write this, and the only<br>> way I can find to discover the available parameter names is to look<br>> in /usr/include/bits/confname.h to see what is defined. I can't<br>> spot any other way to get at the information, and I can't find any<br>> runtime utility that provides a listing.<br>><br>> But a little utility program that could be used to update the<br>> pool might be good enough. Attaching an example C program, I'm<br>> not sure if it helps.<br>><br>> Dave<br>><br>><br>>> On Tue, Oct 13, 2020 at 01:49:00PM -0700, Eliot Miranda wrote:<br>>> Hi David,<br>>><br>>>> On Mon, Oct 12, 2020 at 8:28 PM David T. Lewis <lewis@mail.msen.com> wrote:<br>>>><br>>>> 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<br>>>> this<br>>>>> points to the issue for which FFI pools are needed, the constant names<br>>>> 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<br>>>> 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>>>><br>>><br>>> Well, I *am* implementing it as an FFI call in Terf. The issue is deriving<br>>> the right integer values for the particular symbolic names, because these<br>>> vary across implementations. And that's what FFIPools are designed to<br>>> manage.<br>>> Right now I don't have the FFIPool so I've hard-wired the constant:<br>>><br>>> !CMacOSXPlatform methodsFor: 'accessing' stamp: 'eem 10/11/2020 17:53'<br>>> prior: 47990341!<br>>> numberOfCPUs<br>>> "Warning, warning, Will Robertson!!!! The sysconf method bakes in a<br>>> decidedly implementation-specific name for the support library *and* bakes<br>>> in a value for a symbolic constant. Both of these are implementation<br>>> dependent and subject to change. That said..."<br>>> ^self sysconf: 58<br>>><br>>> "CPlatform current numberOfCPUs"! !<br>>> !CMacOSXPlatform methodsFor: 'private' stamp: 'eem 10/11/2020 17:51'!<br>>> sysconf: systemInfo<br>>> "Answer a value from sysconf(3)."<br>>> <apicall: longlong="" 'sysconf'="" (long)=""></apicall:><br>>> '/usr/lib/system/libsystem_c.dylib'><br>>> ^self externalCallFailed<br>>><br>>> " | scnprocsonline |<br>>> scnprocsonline := 58.<br>>> self current sysconf: scnprocsonline"! !<br>>><br>>> There's much to be unhappy about in this code: libSystem.dylib is the<br>>> abstract name, but one can't use it because the search facilities can't<br>>> chain through the libraries that libSystem.B.dylib (ibSystem.dylib is a<br>>> symbolic link) refers to. So this could break in some future MacOS,<br>>> whereas if libSystem.dylib did work, or if there was a symbolic name we<br>>> could use that meant "the C library goddamnit", then it could be relied<br>>> upon. 58 is meaningful only on MacOS, and presumably only since a<br>>> particular version. That's why we need an FFIPool to manage the<br>>> cross-platform variations. The type is longlong, which means we're not<br>>> using a syntax that matches the declaration, and this will work only on<br>>> 64-bits. We can fix the FFI to interpret C names accoding to the<br>>> playtform, but we have a serious backwards-compatibility problem in that<br>>> all of the FFI definitions up til now have been written under this<br>>> assumption.<br>>><br>>> 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>>>><br>>><br>>> First off Terf needs _SC_NUM_PROCESSORS_ONLN, which is notionally the<br>>> number of processors online, but now answers the number of cores, which<br>>> shows you how fast these ideas go stale (_SC_NUM_PROCESSORS_CONF is the<br>>> number of processors configured ;-) ). Other ones that could be meaningful<br>>> for applications include _SC_ARG_MAX (The maximum bytes of argument to<br>>> execve(2)) _SC_CHILD_MAX (The maximum number of simultaneous processes per<br>>> user id), _SC_OPEN_MAX (The maximum number of open files per user id),<br>>> _SC_STREAM_MAX (The minimum maximum number of streams that a process may<br>>> have open at any one time), _SC_PHYS_PAGES (The number of pages of physical<br>>> memory).<br>>><br>>> There are many others, quite a few I can't imagine ever being compelling.<br>>><br>>> Now yes, one can imagine implementing a cross-platform abstraction for<br>>> these but it's a lot of effort for little gain. It;s easier just to suck<br>>> it up and implement the FFI call.<br>>><br>>> But I'm imagining these things will get used by the community and I don't<br>>> want people to have to reinvent the wheel. This kind of stuff doesn't<br>>> belong in trunk, but it does belong somewhere where we can share and<br>>> coevolve the facilities.<br>>><br>>><br>>>> Thanks,<br>>>> Dave<br>>>><br>>>><br>>>><br>>><br>>> --<br>>> _,,,^..^,,,_<br>>> best, Eliot<br>><br>>><br>><br>> <scparams.c><br></scparams.c></lewis@mail.msen.com></lewis@mail.msen.com></div></blockquote>
</div></body>