Indeed. We did some work with RS485 support for the Serial plugin... EINTRs happen all the time... recommended to retry (see Linux documentation around the web as to why). Obviously, in a plugin, the retry can happen quite quickly. Not sure how using FFI might respond.
Regards, Gary.
----- Original Message ----- From: "David T. Lewis" lewis@mail.msen.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, January 26, 2009 1:50 AM Subject: Re: [squeak-dev] Help needed with select() socket function and signalhandlers in squeakVM
On Sun, Jan 25, 2009 at 08:50:35PM -0200, Mariano Martinez Peck wrote:
Now, I have a problem with select() invocation. This function returns -1. And the printf of the errno (where select() stores the errors), says: "Error with select function: Interrupted system call" which means I am getting a EINTR error. If you see console, you can see something like this:
timeval tv_usec value: 0 timeval tv_sec value: 3 timeval tv_usec value: 0 timeval tv_sec value: 2 timeval tv_usec value: 996000 timeval tv_sec value: 3 timeval tv_usec value: 0 Error with select function: Interrupted system call
I asked Norbert (openDBX author) and he tell me exactly this:
"An interrupted system call is something very normal because signals can be sent at every time to the application, either by the system or by the user. I guess, in the Squeak code there is some signal handler installed, which does something if one of the defined signals arrive.
What I will do is to hide the consequences (returning an error) by looking at the error value and reenter the select call if the system call is interrupted."
Norbert is correct, and his solution of reentering the system call sounds like the right thing to do.
All I know is squeakVM is written it SLANG and then that's transformed to C. So, squeakVM runs in C. So, there is where it can be a signal handler ? Is there some way to change that from squeak (image) ?
Any interrupt handler will service interrupts for the entire VM, so this is not something that you would want to set up for a specific plugin. If one plugin sets a signal handler, it affects all other plugins as well as the VM itself.
It is actually quite easy to experiment with setting signal handlers if you are using a Unix VM and if you have OSProcess installed. For example, if you want to handle the SIGQUIT signal, you can evualate the expression 'OSProcess accessor forwardSigQuit' to get a Smalltalk semaphore that will be signalled each time the operating system sends a SIGQUIT (signal number 3) to the VM. You can have a Squeak process that waits on the semaphore and does whatever you like.
To be clear however, Norbert's explanation is correct regardless of how the VM chooses to handle a signal. When a system call such as select is interrupted, the application (your plugin) needs to check for this and retry the system call.
HTH,
Dave