Re: Behaviour of wgetch during Signal Handling (EINTR)

[Thomas Dickey]

On Wed, Aug 24, 2016 at 10:11:40AM +0200, Leon Winter wrote:
> Hi,
> 
> we currently use ncurses-6.0+20160625.
> 
> The man page of wgetch claims:
> 
>  Programmers concerned about portability should be prepared  for  either
>  of  two  cases: (a) signal receipt does not interrupt getch; (b) signal
>  receipt interrupts getch and causes it to return ERR with errno set  to
>  EINTR.   Under the ncurses implementation, handled signals never inter-
>  rupt getch.

I recall this being discussed before, and I (seem to) recall working to make
the documentation closer to the actual function.

In this case, I believe the comment (probably originally written by Eric
Raymond) refers to the logic in lib_getch.c which is ifdef'd with HIDE_EINTR. 
The ifdef itself dates from a rewrite by Alexander Lukyanov in August 1997,
and appears to have been "off" since it was added.

My checkin comment summarized Alexander's change:

   Alexander rewrote kgetch, fixes the <esc>F1 bug - but flushinp is still
   broken.
 
> The most interesting sentence in the last one.
> However in my application I am now seing this (trace):
> 
>  end twait: returned -1 (4), remaining time 549253 msec
> 
> The wgetch function returns with ERR on that occasion. So it seems the man 
> page
> is wrong. I checked the source code as well and could not identify any loop 
> for
> EINTR which would justify claiming that the function would never be 
> interrupted.
> In my specific use case, I have a child process terminating at the time I am
> waiting for user input in wgetch (). There is a signal handler installed for
> SIGCHLD (which is called) but ncurses does not seem to handle EINTR in their
> select loop.
> 
> Should the man page be fixed to reflect the actual behaviour or should the 
> code
> be changed?

documentation is easier to change :-)

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

signature.asc
Description: Digital signature