bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multi-threaded output


From: Steven Seeger
Subject: Re: Multi-threaded output
Date: Mon, 25 Oct 2004 17:19:22 -0700
User-agent: Microsoft-Entourage/11.0.0.040405

Hi Thomas,

I managed to solve the problem. What I've done here is create a whole C++
framework for curses that includes classes like cWindow, cButton, cTextBox,
cLabel, cLabelExt (labels with justification and etc), cSelectBox, and etc,
with full support for attributes and multithreading. Curses calls are done
through a single instance curses manager class macro that looks like this:

#define curses_safe(x, ...) { _safelock(curse->get_mutex()); x(__VA_ARGS__);
safeunlock(); }
#define curses_safe_ret(x, y, ...) { _safelock(curse->get_mutex()); x =
y(__VA_ARGS__); safeunlock(); }

This allows me to wrap all calls to curses around a mutex.

The solution to my problem did lie with a fix around getch, just as you
suggested. I used select to wait for stdin, and then when a key comes in I
can then use curses_safe() around wgetch on my front-most window without
stalling the updating threads, as wgetch returns almost immediately. If I
tried to use the macro around it before everything would wait for keyboard
input. I put a 50ms timeout on select in case the front window changes,
though in the program I'm making this requires a function key press.

Thanks again!

Steve

On 10/25/04 5:12 PM, "Thomas Dickey" <address@hidden> wrote:

> On Mon, 25 Oct 2004, Steven Seeger wrote:
> 
>> On 10/25/04 4:16 PM, "Thomas Dickey" <address@hidden> wrote:
>> 
>> Hi Thomas. Thanks for writing me back.
>>> 
>>> ncurses isn't thread-safe.  Occasionally someone asks about it, but no
>>> one's done any work to make this happen.
>> 
>> Not me. :)
> 
> It's probably worth the effort (I've found no lack of other things to
> do, however).
> 
>>> getch does a refresh.  If your other threads are running concurrently
>>> and updating the screen, it won't work.
>> 
>> Perhaps getch is corrupting my screen? I didn't put a mutex around it as I
> 
> That's my offhand guess.  getch does a refresh before it settles down
> to wait for input.  There's also the (less-used) path in getch which
> makes it echo input as it's read, which also requires refresh.
> 
>> didn't think I had to, as it blocks until input comes in, and the thread
>> that's drawing the screen has a higher priority than the one calling getch
>> so I figured the getch thread wouldn't run until the higher priority draw
>> one is finished.
>> 
>>> 
>>> If you added a mutex to refresh and getch, there's still the places
>>> that would update the screen (a lot of places).  Probably the simplest
>>> way to go would be to add an entrypoint to ncurses that provides the
>>> mutex, use that in blocks of code that would do updates.  That way
>>> you wouldn't be locking/unlocking things down at the character level.
>> 
>> What do you mean by add an entry point?
> 
> A function.  I haven't looked at threads for quite a while, but as I
> recall it, you can make a mutex by associating it with a user-supplied
> variable.  A function that would do either the lock or unlock depending
> on a second parameter would be usable also by getch, e.g., if you made
> the variable something like the WINDOW* which it uses as a parameter.
> 
> Something like that (particularly if its interface didn't introduce new
> datatypes or includes) would be useful as an extension to ncurses.  Aside
> from the WINDOW's, the other global variables that come to mind (COLS,
> LINES) which are frequently used could be replaced by macros that evaluate
> to functions which wrap a mutex, e.g., to prevent one thread from resizing
> the screen while another is repainting.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]