Re: Semaphores failing to prevent race condition

Llew_Llaw_Gyffes:

Generally I don't let multiple threads talk to the terminal, mostly because of the problems you're experiencing right now. Instead, I tend to let asynchronous tasks add their complete messages to a queue, and have one thread (usually the one starting all the others) poll the queues and print messages.

The primary difficulties of sharing a terminal with multiple writers is due to (1) buffering (see suffering from buffering), and (2) you can task switch in the *middle* of an escape sequence. So you get text out of the expected sequence, and in the wrong locations and colors due to the broken escape sequences.

If you give each thread an array that they can put complete messages into, and have one thread grabbing distinct messages and printing them, you can more easily manage your terminal.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Update: Corrected name.

Comment on Re: Semaphores failing to prevent race condition

Replies are listed 'Best First'.
Re^2: Semaphores failing to prevent race condition by Llew_Llaw_Gyffes (Scribe) on Mar 13, 2011 at 17:33 UTC
So possibly a single screen-interaction thread with messages passed to it via Thread::Queue, then?	[reply]
Re^3: Semaphores failing to prevent race condition by roboticus (Chancellor) on Mar 13, 2011 at 18:12 UTC
Sure thing. ...roboticus When your only tool is a hammer, all problems look like your thumb.	[reply]
Re^4: Semaphores failing to prevent race condition by Llew_Llaw_Gyffes (Scribe) on Mar 13, 2011 at 19:18 UTC
I've been trying to figure out how I could do this, and while I'm not going to come right out and way that it can't be done in this way, it's going to be non-trivial. The inter-thread interface is going to be extremely complex, because while the listener and status threads simply print complete messages to the screen, the talker thread outputs one character at a time and does direct character positioning. However, what I can possibly do is have the talker thread be the thread that does all the screen I/O for the other threads, in between listening for keyboard events. This would eliminate the need to figure out how to send its readline-like events as messages, and would satisfy the goal of having all I/O occur in a single thread.	[reply]
Re^5: Semaphores failing to prevent race condition by roboticus (Chancellor) on Mar 14, 2011 at 19:31 UTC
Re^2: Semaphores failing to prevent race condition by Llew_Llaw_Gyffes (Scribe) on Mar 13, 2011 at 19:13 UTC
Oh, BTW, buffering isn't going to help in this case because there is no I/O direct to a filehandle. All output is sent to Curses window objects as addstr(), erase(), etc.	[reply]