List Status Test-----NEXT QUESTION?

[Fairlight]

On Fri, May 12, 2017 at 05:19:50PM +0000, Richard Kreiss via Filepro-list
thus spoke:
> One thing I would love to see would be the ability of filePro to make use
> of all of a chips processors to better balance the performance. i.e. Load
> clerk in one processor and if a system call is made, check to see which
> processor has the least load and run it in that processor.  This may
> also make it possible to have Windows run a report or index rebuild in
> background similar to what the *nix version does.

That's already happening, at least on Linux, or any sane SMP
implementation.  Any time SYSTEM is invoked, a bash shell sits between the
parent filePro process and the child, and that shell and then the child
filePro process should be placed on the last busy cores at the times
they're created.

If Windows doesn't do that, then the Windows SMP isn't very S.  :)

As far as native filePro threading...  Never. Going. To. Happen.  If they
haven't rewritten it to make use of simpler techniques like select()
(which would be flippin' awesome to stick in the "A filePro error has
occurred" routine, so we don't see five quadrillion read(0,[...]) = -1
syscalls per second when there's a 'crash', thus sucking 100% of whatever
is left of the core that process is on), I don't see a snowball's
chance in hell of them incorporating libpthreads or similar.  Threading
is also pretty platform-dependent.  Even Linux binaries used to (and
may still...haven't checked in ages due to lack of need) have multiple
threading models available.  It'll differ almost entirely under Windows.  I
just can't see them ever making that happen.

And to be fair, it doesn't need to be threaded.  I've seen some reports
which slurp CPU, but probably 90%+ of what you do in filePro in terms of
resource contention is actually I/O-bound, not CPU-bound.  Even I can't
make a good case for native threading within the binaries, because they do
so little with the CPU in most cases.  Ironically, the time that filePro
uses the most CPU is actually when you've hit that error condition in the
previous paragraph.  Seriously.  I'm absolutely dead serious that that is
the biggest offender.

The OS should be handling what little core allocation you need, and does
so under Linux.

mark->
-- 
Audio panton, cogito singularis.