How to wait for key, mouse OR other thread's event in ncurses app?

How to wait for key, mouse OR other thread's event in ncurses app?

Post by Wojciech Zabolotn » Fri, 27 Sep 2002 16:52:40



Hi All,

  I have to write a small multithreaded terminal based application.
One thread (A) will be responsible for user interface (implemented
with ncurses+cdk). Another one (B) will be responsible for analog-digital
converter I/O, and the third one (C) will be responsible for network
communication.

  The events generated by threads (B) and (C) should trigger appropriate
actions in the user interface widgets. However I can't be sure that
the ncurses+cdk implementation will be threadsafe. Therefore I need a
method to wait in thread (A) for key event, or mouse event, or event
generated by other threads.
  I wouldn't like to use any busy-wait loop (with wgetch in no-delay
mode, and checking other threads' variables), because the system
performance is essential in this application (and other apps will run
simultaneously).

Currently I can imagine two solutions:
1) The events in (B) and (C) threads will simulate the special key events
   which will be serviced by standard wgetch function (but how to do it
   in a threadsafe way)?
2) The thread (A) will be waiting on select function for either stdin
   events (the key events are read from there in ncurses, aren't they?)
   or special pipe events. The threads (B) and (C) will write single byte
   "messages" to that pipe to trigger processing in (A) thread.
   Well, but in this case:
   a) I'll loose the mouse events in ncurses
   b) This approach is really complicated

Is there any simpler, more elegant solution?
Thank you in advance for any hints, pointers and so on (even RTFM are
appreciated when supported by appropriate URL ;-) ).

--
                        TIA & Best regards,
                        Wojtek Zabolotny

 
 
 

1. How to wait for key, mouse OR other thread's event in ncurses app?

Hi All,

  I have to write a small multithreaded terminal based application.
One thread (A) will be responsible for user interface (implemented
with ncurses+cdk). Another one (B) will be responsible for analog-digital
converter I/O, and the third one (C) will be responsible for network
communication.

  The events generated by threads (B) and (C) should trigger appropriate
actions in the user interface widgets. However I can't be sure that
the ncurses+cdk implementation will be threadsafe. Therefore I need a
method to wait in thread (A) for key event, or mouse event, or event
generated by other threads.
  I wouldn't like to use any busy-wait loop (with wgetch in no-delay
mode, and checking other threads' variables), because the system
performance is essential in this application (and other apps will run
simultaneously).

Currently I can imagine two solutions:
1) The events in (B) and (C) threads will simulate the special key events
   which will be serviced by standard wgetch function (but how to do it
   in a threadsafe way)?
2) The thread (A) will be waiting on select function for either stdin
   events (the key events are read from there in ncurses, aren't they?)
   or special pipe events. The threads (B) and (C) will write single byte
   "messages" to that pipe to trigger processing in (A) thread.
   Well, but in this case:
   a) I'll loose the mouse events in ncurses
   b) This approach is really complicated

Is there any simpler, more elegant solution?
Thank you in advance for any hints, pointers and so on (even RTFM are
appreciated when supported by appropriate URL ;-) ).

--
                        HTH & Best regards,
                        Wojtek Zabolotny

2. Problems compiling slackware 1.2.13 kernel

3. setting mouse button event to key press event

4. enlightenment

5. Ins key in ncurses applications?

6. TFS

7. ncurses and pthreads - how to send event from other thread?

8. "Sound" advice?

9. 'Thread Event Analyzer Program' for Solaris

10. Solari 2.4 sockets, threads, and 'Pollable Event'

11. How to interrupt thread waiting in call to 'select' ?

12. Mapping mouse events to keys

13. Ncurses doesn't wait for refresh()