This is the mail archive of the cygwin-patches mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Mon, Apr 02, 2012 at 09:50:17PM +0200, Thomas Wolff wrote:Yes, that's why I mentioned problem 1 above. The patch is experimental, and it revealed that even if the missing relation could be properly established, there's still the other problem... (see below).Am 02.04.2012 20:50, schrieb Christopher Faylor:On Mon, Apr 02, 2012 at 08:46:31PM +0200, Thomas Wolff wrote:...... * semi-fix for missing terminal status responses The fix tries to detect the proper fhandler for CONIO, which is then used to queue the response. Problem 1: I am not sure whether this detection is proper in all cases, what e.g. if /dev/tty is reopened etc. I don't know where else a relation between the handles for CONIN and CONOUT might be established. Problem 2: While the response reaches the application with this patch, only the first byte is read right-away. Further bytes are delayed until other input is becoming present (typing a key). This may (or may not) be related to other issues with select(), so maybe it's worth analyzing it.
Thomas diff -rup sav/fhandler.h ./fhandler.h --- sav/fhandler.h 2012-04-01 19:46:04.000000000 +0200 +++ ./fhandler.h 2012-04-02 15:47:22.385727000 +0200 @@ -1282,8 +1282,11 @@ class dev_console
bool insert_mode; int use_mouse; + bool ext_mouse_mode6; + bool ext_mouse_mode15; bool use_focus; bool raw_win32_keyboard_mode; + fhandler_console * fh_tty;
inline UINT get_console_cp (); DWORD con_to_str (char *d, int dlen, WCHAR w); diff -rup sav/fhandler_console.cc ./fhandler_console.cc --- sav/fhandler_console.cc 2012-04-02 00:28:55.000000000 +0200 +++ ./fhandler_console.cc 2012-04-02 18:02:26.004016200 +0200 @@ -139,6 +139,8 @@ fhandler_console::set_unit () if (shared_console_info) { fh_devices this_unit = dev (); + if (this_unit == FH_TTY) + dev_state.fh_tty = this;You *definitely* just can't squirrel away a pointer to a random fhandler here.`this' is a pointer to a fhandler. You can't just store it in a static location and use it whenever you want later. You have no idea how long this fhandler will be around. What happens if it's destroyed?
My point is: The function that doesn't work here, puts_readahead/put_readahead,If you have an example of actual failing code then please post it.Do we really care about console mode that much now that mintty is the default?Maybe not, but the fact that it works partially but subsequent characters are postponed resembles the other problem that I have just reported tocygwin@cygwin.com, which makes me wonder whether there is one common problem.
Also when I originally tweaked the mouse code, I couldn't completely understand the code in select.cc (only got it to work by pattern matching code...). I did notice, however, that select and read were inconsistent in the sense that an application having called select() with a positive response may not be able to get a byte with a subsequent read(), because criteria were re-evaluated and could have different results (esp. in border cases). I did fix it by strictly applying the same guard routine for both cases, but only for the mouse code branch.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |