bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

On Tue, May 13, 2014 at 8:14 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Tue, 13 May 2014 19:58:58 +0200
>> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
>>
>> On Tue, May 13, 2014 at 7:50 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> From: Michael Heerdegen <michael_heerdegen@web.de>
>> >> Cc: 17392@debbugs.gnu.org
>> >> Date: Tue, 13 May 2014 18:04:14 +0200
>> >>
>> >> Before spending time in debugging, I studied the related lisp code in
>> >> frame.el and timer.el.  AFAICT, you can't explain what I see exclusively
>> >> by bugs in that code.
>> >
>> > I don't see how this can be explained except by some race condition.
>> > And I don't see how can a race condition happen here, since both Lisp
>> > and C code involved in this are supposed to be run by the same
>> > single-threaded Lisp interpreter.
>>
>> The race condition could be elsewhere, of course.
>
> Like where?

I don't know, but as I said I have seen this and several other things
that looked like they could be caused by race conditions. At that time
I suspected they were w32 specific, but this discussion makes me think
I was wrong.

For me it was difficult to understand the division among threads. I
suspected there was something wrong, but it is a big job going through
that. (I made some changes in EmacsW32, but that was years ago and I
do not remember them now.)

What could be done to make this easier is checking the return value of
every single system call. (At least as an option.) That could help to
catch cases where race conditions sometimes occur. Do I remember this
wrong? Does not the documentation for some system calls explicitly say
that you should check because the may fail (maybe in some strange
conditions).

I said that before, of course. And I am no expert on this so I might be wrong.