public inbox for cygwin-developers@cygwin.com
 help / color / mirror / Atom feed
From: Thomas Wolff <towo@towo.net>
To: cygwin-developers@cygwin.com
Subject: Re: read vs select on mouse events in console
Date: Fri, 23 Dec 2022 10:08:20 +0100	[thread overview]
Message-ID: <17a52f3b-c8c4-b4dc-c852-93d5fcb22888@towo.net> (raw)
In-Reply-To: <20221223122408.e2412a32f5ab1bca115a8ae6@nifty.ne.jp>

Hi Takashi

Am 23.12.2022 um 04:24 schrieb Takashi Yano:
> Hi Thomas,
>
> On Thu, 22 Dec 2022 15:55:01 +0100
> Thomas Wolff wrote:
>> When I added mouse notification support to the console long ago, I
>> deliberately introduced a function mouse_aware() which was common
>> between the console version of function read() and the console branch of
>> function select(), in order to make sure by design that inconsistencies
>> between them could never occur.
>> Now I noticed that by some change, mouse_aware() is not used anymore in
>> select() code.
>> This means that it could happen that either a mouse event would be
>> indicated by select() but then not be delivered by read(), so read()
>> could stall,
>> or (possibly, not sure) the other way round, a mouse event available for
>> delivery would not be recognized by select().
>> The attached test case is a rough demonstration of the issue. It uses
>> mouse mode DECSET 1000 which has a limited range of mouse coordinates.
>> Run it in a maximized console, click into the upper left area, then
>> further apart toward lower right, and eventually the program will stall
>> until another key is pressed.
> mouse_aware() is called from process_input_message(). Currently,
> both read() and select() call process_input_message(). So,
> mouse_aware() is processed in both read() and select(), I think.
>
> Therefore, if mouse event has some problem, the cause should be
> something another.
>
> Could you please explain about your test case more detail a bit?
> What are the expected behavior and the current behavior?
>
> I tried:
> 1) Maximize command prompt.
> 2) Start \cygwin64\bin\bash -l
> 3) Start your test case.
> 4) Then, "(0)" is displayed every one second.
> 5) If push down mouse left button at top left corner, some message is shown.
> 6) Another message is shown when release mouse left button.
> 7) Move mouse cursor to bottom right corner.
> 8) Clicking mouse does not generate any message.
> 9) "(0)" is still displayed every one second.
>
> Is this different from your observation? Or do you expect different behavior?
I see different behavior indeed; no further output of (0) and Windows 
display its message to make a mouse selection in the title bar.
The purpose of the test program is to check whether select() reports 
something available, then read it to actually verify and display the input.
OK, I overlooked the nesting in process_input_message, so maybe it's OK, 
but then still my observation of the test case is mysterious. I'll look 
further into it, but not so soon...
Thanks
Thomas

  reply	other threads:[~2022-12-23  9:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-22 14:55 Thomas Wolff
2022-12-23  3:24 ` Takashi Yano
2022-12-23  9:08   ` Thomas Wolff [this message]
2022-12-23 10:19     ` Takashi Yano
2022-12-23 12:03       ` Thomas Wolff
2022-12-24 11:37         ` Takashi Yano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17a52f3b-c8c4-b4dc-c852-93d5fcb22888@towo.net \
    --to=towo@towo.net \
    --cc=cygwin-developers@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).