> Am 14.11.2022 um 15:41 schrieb Dave Jones <vmda...@gmail.com>: > > Hello, all. > Does this problem occur when the virtual machines are hosted by a *real* > hypervisor, namely z/VM? :-)
I which I had a S/390 running z/VM to play with. And a nuclear reactor to power it with... > Or is it just something that happens on VMWare? We use Oracle VirtualBox, not VMWare but I think it is the underlying (desktop) hardware that creates the timing fuss. > MAny thanks. > DJ > > On Sun, Nov 13, 2022 at 1:39 PM Mike Cowlishaw <m...@speleotrove.com > <mailto:m...@speleotrove.com>> wrote: > OK, thanks! > > From: Rick McGuire [mailto:object.r...@gmail.com > <mailto:object.r...@gmail.com>] > Sent: 13 November 2022 11:13 > To: Open Object Rexx Developer Mailing List > Subject: Re: [Oorexx-devel] Jenkins > > > > On Sun, Nov 13, 2022 at 5:57 AM Mike Cowlishaw <m...@speleotrove.com > <mailto:m...@speleotrove.com>> wrote: > > >> I'm not familiar with internals of ooRexx, but reading this: >> >>> I tried to "tune" Virtualbox to get rid of the timing error >>> problems but every attempt actually made things worse, with >>> more than half of the timing tests failing. I have reset >>> Virtualbox to default values now. What *DID* help on the >>> other hand was to deprive the VMs of resources. Changing from >>> 2 cores/4 GB memory to 1 core/ 2 GB memory made all *nixes >>> pass all tests, so it looks like the problem were related to >>> Virtualbox rather than to ooRexx. Only exception are the >>> BSDs, that are still a bit problematic to test. But all >>> platforms (Win macOS Linux Unix) build without error now. >> >> makes me wonder a bit: by reducing to one core then anything multithreaded >> is forced to run on a single thread which makes race conditions much less >> likely than when on multicore where multiple threads can run simultaneously. > > ooRexx is not truly multithreaded. Only one thread at a time is allowed to > run Rexx code at a time, with a cooperative internal dispatch mechanism. Only > threads running external code (e.g., calls to native libraries or running > commands) truly run concurrently. Multiple cores might affect the timing of > which thread happens to get permission to run next, but which thread gets > permission has always been unpredictable. > > >> > Which means that there can be no unexpected time glitches between threads > since they run consecutively on one core. And that ooRexx handles any such > race conditions GREAT. This shows IMO how robust ooRexx 5 has become. Gold > standard ;-) > > Right, but in the real world it will be running on multicore machines... > > The failing test cases run just fine on multicore machines, they only seem to > fail in multicore virtual machines. Also, the failures don't really appear to > be race conditions, but rather checks in timer values that are falling > outside expected ranges. There's something funny going on with the clocks in > the virtual machines in those situations. > > > > Mike > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net <mailto:Oorexx-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net <mailto:Oorexx-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
