[argyllcms] Re: Spotread stalling sometimes under Windows
- From: François Simond <color@xxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Wed, 18 Nov 2015 04:13:02 +0100
On Tue, Nov 17, 2015 at 8:04 AM, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
François Simond wrote:
Sounds like a race condition - the thread doing the stdin read
probably got killed just as the character arrived. I don't have any
clever ideas for solving this at the moment, since stdin has
to be poll-able and also readable in other ways in other places in
the code.
Yes it appears to be that.
Do you think it would be possible to add in the stdout or stderr debug
output an equivalent of "take_emis_measurement called" that would be
the same for all sensor drivers ?
Maybe.
I've come up with another approach though, that may work better
for programmatic operation. Try this spotread binary:
<http://www.argyllcms.com/spotread_win32.zip>
and see if it's any better.
(It's more flakey when driven from the console with
ARGYLL_NOT_INTERACTIVE=1 though.)
This new approach produces solid results.
I took many hours to run stress tests with several parameters using
the same tool as before on the Atom D525 machine which was failing
easily under Windows 7:
i1 Display Pro, 4 CPU load threads: 14145 readings (stopped manually)
i1 Display Pro, 20 CPU load threads: 1726 readings (stopped manually)
i1 Pro, 12 CPU load threads: 361 readings (expired calibration)
i1 Pro, 12 CPU load threads: 929 readings (expired calibration,
brighter patches)
i1 Display 2, 12 CPU load threads: 3310 (stopped manually)
I wasn't able to reproduce a single failure with any of the instruments.
Tomorrow I'll try again with a couple different tests but already, congrats!
Your change appear to be an excellent solution; even with
ARGYLL_NOT_INTERACTIVE=1 it can't be call it flaky at all :)
--
François
Other related posts:
