Hello, all. Does this problem occur when the virtual machines are hosted by a *real* hypervisor, namely z/VM? :-) Or is it just something that happens on VMWare? MAny thanks. DJ
On Sun, Nov 13, 2022 at 1:39 PM Mike Cowlishaw <m...@speleotrove.com> wrote: > OK, thanks! > > ------------------------------ > *From:* Rick McGuire [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> > 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 >> 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
