Thanks for the simple testcase. This is actually a long standing issue with READ *X in that it was not handling the case of an interrupt due to a Unix signal. Thankfully until GT.M V5.1-000 there were no such periodic indefinite signals so things were working fine.
In GT.M V5.1-000, to fix another issue, we introduced a periodic 8-second heartbeat timer (in every GT.M process that opens the database) that will cause a signal (SIGALRM) to be received. This has now exposed the READ *X issue where the read that is waiting for the timeout gets interrupted by the signal and restarts the read (without counting the time that it has already waited) basically waiting indefinitely in a loop for the specified timeout to occur without interrupts. We will fix this in a future release.
Sorry for the delay in responding. We are trying to wrap up the release of GT.M V5.2-000.
Thanks,
Narayanan.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello all,
there seems to be a small read timeout bug in GT.M Version 5.1.000
Consider the following little program:
S DUMMY=$D(^DUMMY) U $P F I=1:1 R *X:I Q:$T W !,I
While running this program without keyboard input
you will see variable I up to 8
with other words:
R *X:9 will hang forever, also R *X:10 and so on.
Surprisingly, R X:9 is waiting exactly 9 seconds and exits!
It is necessary to open the database (accessing some globals)
Without connection to a database this timeout problem cannot be observed.
Workaraound:
avoid R *VAR:T with T>8
With kind regards
Martin
Hi Martin,
Thanks for the simple testcase. This is actually a long standing issue with READ *X in that it was not handling the case of an interrupt due to a Unix signal. Thankfully until GT.M V5.1-000 there were no such periodic indefinite signals so things were working fine.
In GT.M V5.1-000, to fix another issue, we introduced a periodic 8-second heartbeat timer (in every GT.M process that opens the database) that will cause a signal (SIGALRM) to be received. This has now exposed the READ *X issue where the read that is waiting for the timeout gets interrupted by the signal and restarts the read (without counting the time that it has already waited) basically waiting indefinitely in a loop for the specified timeout to occur without interrupts. We will fix this in a future release.
Sorry for the delay in responding. We are trying to wrap up the release of GT.M V5.2-000.
Thanks,
Narayanan.
Hi Martin,
For your reference, the tracking number S9G11-002628 has been assigned to this issue.
Thanks,
Narayanan.