[argyllcms] Re: Spotread stalling sometimes under Windows

  • From: François Simond <color@xxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Fri, 13 Nov 2015 02:27:32 +0100

On Fri, Nov 13, 2015 at 1:58 AM, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:

François Simond wrote:

When the issue occurs, spotread ends up stalling in an infinite
GetDiffuserPosition loop with zeros as response instead of moving on
to take_emis_measurement.

The GetDiffuserPosition is a background thread - it has nothing to do
with taking readings. There is no indications of problems with
the command it uses (ICOM err 0x0).

From looking at log-1-i1DisplayPro it simply seems that after reading 1453
the driver is not asked to do another reading - i.e. there is no call to
"take_emis_measurement" after that. I don't see a problem with the
ArgyllCMS driver from the logs, so it's either something in your code,
and/or possibly a breakdown in the triggering.

Your explanation makes most sense.
Indeed in another demo prototype, when sending another character and
flushing to spotread.exe stdin when it was stalled, it would accept
the new read command, resuming the reading loop operation normally.

It is like spotread.exe never received one of the command.


If changing PRE_DELAY_MS and POST_DELAY_MS has an effect, then I'd suggest
using values that don't trigger the problem - there's some
tricky interaction with the operating system going on there
in dealing with stdin, to deal with limitations of the Win32
API - see spectro/conv.c poll_con_char() for an explanation.
You probably need to slow it down a lot - i.e. try delays > 200msec.

Yes the delays was an initial approach that lead to trigger the bug a
bit more often (but still not that often)
However when maxing out the CPU with multiple threads or an external
program, it is producing the error usually before completing 35
readings.

Graeme Gill.





--
François

Other related posts: