On Monday 10 January 2011 19:25:48 Gilles Chanteperdrix wrote:
> Peter Soetens wrote:
> > On Monday 10 January 2011 17:24:28 Gilles Chanteperdrix wrote:
> >> Peter Soetens wrote:
> >>> Hi,
> >>> 
> >>> A while ago, I was advised to call xeno_sigshadow_install() after a
> >>> library installed a sigwinch signal handler (I believe this was Xenomai
> >>> 2.5.1). Could it be that this is no longer supported in recent versions
> >>> ? What is the correct way to avoid a segfault if an application
> >>> installed a sigwinch handler after Xenomai did ?
> >> 
> >> I think we already answered that at the time, but if you install your
> >> own sigwinch handler, you should:
> >> - register it with the SA_SIGINFO flag
> >> - call xeno_sigwinch_handler and consider that the signal is for the
> >> application only if this function returns 0.
> > 
> > This is indeed in the API docs, but it's not an option since it's a third
> > party library (readline) doing this, it doesn't depend on or know
> > Xenomai.
> 
> Actually, readline behaviour is highly configurable, and looking a bit
> at its documentation, we find that its behaviour with regard to sigwinch
> is configurable, see:
> rl_catch_sigwinch
> rl_resize_terminal

But we *want* to catch sigwinch/resize_terminal, since this happens quite 
often. Without this signal the terminal width is not being communicated to the 
readline library and it displays its columns in a too large or too small 
width.

It's the terminal emulator giving us this signal, and it is meaningful to us. 
It's Xenomai doing something fundamentally flawed, or I fundamentally 
misunderstand it. Why can't you register a signal handler, without interfering 
with other handlers for the same signal ?

Peter

_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help

Reply via email to