Could the VM provide an option for separating its own output from the image's output?
Concretely, the VM complains about pthread_setschedparam in my Travis builds, which prevents writing command-line scripts with clean output both on stdout and stderr. See https://github.com/hpi-swa/smalltalkCI/issues/388
Maybe it's possible to play with the file descriptors at image startup, but it would make sense if the VM itself had something like a `--silent` or a `--vm-stderr FILE` flag (the JVM has `-Xlog`) to redirect its diagnostic messages so that anything that goes to stdout or stderr exclusively comes from the image.
Hi Damien,
On Wed, Aug 8, 2018 at 9:29 AM, Damien Pollet notifications@github.com wrote:
Could the VM provide an option for separating its own output from the image's output?
Yes, I guess it could. But (to state the obvious) this wouldn't help e.g. errors coming from C library code, only explicit error messages from the VM code itself.
Concretely, the VM complains about pthread_setschedparam in my Travis builds, which prevents writing command-line scripts with clean output both on stdout and stderr. See hpi-swa/smalltalkCI#388 https://github.com/hpi-swa/smalltalkCI/issues/388
The thing is, this is worrying. If pthread_setschedparam complains then it likely means you don't have reliable time or delays in the running system. You may be better off using an timer heartbeat VM if your build machine won't support multiple thread priorities. Alternatively it could simply be a issue of the age of the kernel.
Can you post the exact error message and the build machine's kernel version?
Maybe it's possible to play with the file descriptors at image startup, but it would make sense if the VM itself had something like a --silent or a --vm-stderr FILE flag (the JVM has -Xlog) to redirect its diagnostic messages so that anything that goes to stdout or stderr exclusively comes from the image.
Yes, but this would require some intelligence to ensure the VM does answer actual stderr through the primitives that provide access to them (stdioHandles uses the primitiveFileStdioHandles primitive in FilePlugin). So it's not trivial.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/275, or mute the thread https://github.com/notifications/unsubscribe-auth/APHa0KEfhqUkkNSkZ6TO2e2dPJeoZyI6ks5uOxHTgaJpZM4V0Q3j .
_,,,^..^,,,_ best, Eliot
Hi Eliot,
Is there actual proof of issues caused by rtprio not raised correctly or is this more a precaution/speculation? smalltalkCI, for instance, builds hundreds of projects every week and we didn't see any problems when we switched from itimer to threaded VMs.
The easiest fix here, obviously, would be to hide the note all-together and maybe add it to some sort of `README.txt` that ships alongside the binaries. Maybe it could be that simple?
On 08-08-2018, at 1:26 PM, Fabio Niephaus notifications@github.com wrote:
Hi Eliot,
Is there actual proof of issues caused by rtprio not raised correctly
Yup; take a look for messages a couple of years ago about having to edit the files giving permissions for priority manipulation. The earlier Raspberry Pi Cog work suffered from it, for example. IIRC even quite recently there have been people reporting trouble that had machines with pre-kernel 2.6 (?) installed.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim To err is human; to forgive, beyond the scope of the Operating System.
Hi Fabio,
On Wed, Aug 8, 2018 at 1:26 PM, Fabio Niephaus notifications@github.com wrote:
Hi Eliot,
Is there actual proof of issues caused by rtprio not raised correctly or is this more a precaution/speculation? smalltalkCI, for instance, builds hundreds of projects every week and we didn't see any problems when we switched from itimer to threaded VMs.
Absolutely. The symptom is that when there is no idle time then the clock does not advance and delays don't fire. So for example,e, if you spawn a process at userBackgroundPriority that simply loops, delays will not work. Tis is because the VM thread is now always union and hence the heartbeat thread, being at the same priority as the VM thread, never gets a chance to run, and so the heartbeat gets disabled.
If your concern is that the error message itself may be in error, I assure you that it is real, and it is reporting that on the system it is not allowed to spawn threads at higher priority without taking special steps. And indeed this is described in the source code and the error message. It really is there for good reason, not just because I'm anal about it ;-)
The easiest fix here, obviously, would be to hide the note all-together and maybe add it to some sort of README.txt that ships alongside the binaries. Maybe it could be that simple?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/275#issuecomment-411540745, or mute the thread https://github.com/notifications/unsubscribe-auth/APHa0ENm8XYsI9kG-HZaS5oB8KD1aZHGks5uO0l7gaJpZM4V0Q3j .
_,,,^..^,,,_ best, Eliot
According to https://github.com/hpi-swa/smalltalkCI/issues/388#issuecomment-411985528, Pharo builds require threaded VMs on CI infrastructure. Please have a look at #279, another possible solution.
@akgrant43 also thinks a command line flag would be the way to go here (see https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/279#issuecomment-4141...).
Here's one last argument against it that I can think of: the option parser fails on unknown options and that means that CI scripts can only use, e.g., a `-suppress*` option iff supported by the vm, otherwise it will fail. The only way to make that work is to check the version of the vm before opening an image, which in turn adds complexity to CI scripts.
On Sun, Aug 19, 2018 at 10:31:15AM -0700, Fabio Niephaus wrote:
@akgrant43 also thinks a command line flag would be the way to go here (see https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/279#issuecomment-4141...).
Here's one last argument against it that I can think of: the option parser fails on unknown options and that means that CI scripts can only use, e.g., a `-suppress*` option iff supported by the vm, otherwise it will fail. The only way to make that work is to check the version of the vm before opening an image, which in turn adds complexity to CI scripts.
For the unix VM, command line arguments are (or should be) supported by environment variables. See function vm_parseEnvironment() for environment variables that match with various corresponding command line arguments.
If you follow this pattern, then you woould define a new command line parameter as previously suggested, and also a new environment variable to do the same thing. With that approach, you can use the environment variable that does what you want, rather than adding special-case handling for ${CI}.
Dav
On Sun, Aug 19, 2018 at 1:32 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Aug 19, 2018 at 10:31:15AM -0700, Fabio Niephaus wrote:
@akgrant43 also thinks a command line flag would be the way to go here
(see https://github.com/OpenSmalltalk/opensmalltalk- vm/pull/279#issuecomment-414133977).
Here's one last argument against it that I can think of: the option
parser fails on unknown options and that means that CI scripts can only use, e.g., a `-suppress*` option iff supported by the vm, otherwise it will fail. The only way to make that work is to check the version of the vm before opening an image, which in turn adds complexity to CI scripts.
For the unix VM, command line arguments are (or should be) supported by environment variables. See function vm_parseEnvironment() for environment variables that match with various corresponding command line arguments.
If you follow this pattern, then you woould define a new command line parameter as previously suggested, and also a new environment variable to do the same thing. With that approach, you can use the environment variable that does what you want, rather than adding special-case handling for ${CI}.
Good suggestion David.
Dav
vm-dev@lists.squeakfoundation.org
-
Damien Pollet -
David T. Lewis -
Eliot Miranda -
Eliot Miranda
-
Fabio Niephaus
-
tim Rowledge