[argyllcms] Re: Spotread stalling sometimes under Windows
- From: François Simond <color@xxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Fri, 13 Nov 2015 02:37:38 +0100
On Fri, Nov 13, 2015 at 2:20 AM, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
François Simond wrote:
Alright I managed to reproduce a similar issue with a i1 Pro spectro
as sensor instead.
That looks like a very different problem - the USB read of the
raw measurement values has timed out. I've no idea why from
the log (USB hardware problem ?).
I will retry with the same parameters on the same machine booting Linux instead.
It could be a the USB port acting up electrically under maximum CPU load.
Meanwhile I ran the same stress test on another Linux machine with the
i1Pro, and instead of failing quickly it reached the point where it
requests a new calibration after almost a thousand readings:
Result is XYZ: 265.783643 270.932687 335.207395, D50 Lab: 145.713071
4.023201 -40.338008
Got reading: 962 elapsed: 1374ms
Spot read needs a calibration before continuing
Place cap on the instrument, or place on a dark surface,
or place on the calibration reference,
and then hit any key to continue,
So it's not only with the i1 Display Pro driver, more like Windows
spotread behavior on a machine slow or under load.
Linux spotread is unaffected.
Yes. The code is tricky - you need to give it some time
to work properly. Linux/OS X doesn't have the same API issue.
[ The basic problem is that there is no Win32 API to poll
stdin for a character when stdin has been opened by someone else,
and so doesn't have the FILE_FLAG_OVERLAPPED set.
So the hack workaround is to start a thread to block on reading
stdin, and then every 100msec cancel I/O on stdin and kill the thread,
and then do it all over again.
No surprise at all if there is some sort of race condition or loss of
a character if you push that whole thing too hard.
]
That's correct.
When trying to investigate the issue earlier in argyll's code I ended
up around poll_con_char(void) but then was unable to solve the issue.
Argyll 1.4.0 was not affected by the issue described and it seems
there was a rewrite after that, when comparing the version's code.
Maybe the older routines used to poll Windows stdin were more reliable?
--
François
Other related posts:
