$stdin.gets, threads, and command-line app

Hi,

I am currently working on a console-based app, in which the user
interacts by entering commands from within a prompt (e.g. sort of a
bash-like app).
One thread for the prompt, some others for computation.
I allowed those threads to output to the console, but it leads to a
really not user-friendly behaviour. Example:

prompt: lis <- started to type in the “list” command
Blablabla from Thread1 <- output to $stdin by threads
prompt: <- The prompt is re-displayed, the command
“seems” lost

prompt: list <- Type again the command “list”
Error: lislist: Unknown command

See my problem?
How can I get the exact text line to be displayed after a thread output
its message? Or How can I catch a partially typed input?
I thought of syscalls, but didn’t get any results yet.

[Note: Obviously, if I had only input “t” after the thread had
displayed, my command would have been correctly interpreted]

I think your problem is the same as the one I posted a few hours ago.

Please look for subject “Trouble using puts and getc in different
threads”.

Mark

Xav Xav wrote:

Blablabla from Thread1 <- output to $stdin by threads
prompt: <- The prompt is re-displayed, the command
“seems” lost

prompt: list <- Type again the command “list”
Error: lislist: Unknown command

See my problem?
How can I get the exact text line to be displayed after a thread output
its message? Or How can I catch a partially typed input?

By not using threads. The order of input and output is not synchronized
between threads. BTW this is true for all thread uses, not just Ruby.
The
only way to get a reasonable match between input and output is for the I
and O of I/O to be in the same thread.

On 2006.10.23 23:21, Xav Xav wrote:

Hi,

I am currently working on a console-based app, in which the user
interacts by entering commands from within a prompt (e.g. sort of a
bash-like app).

If you are working on a shell, you are welcome to help with rs[1]. If
you are just doing it for learning purposes or implementing a command-
line program, you can use HighLine[2]

[1] http://projects.kittensoft.org/rs/rdoc/index.html
[2] http://highline.rubyforge.org

Paul L. wrote:

By not using threads.

In this problem, one should consider the output generated by the threads
is not context-sensitive (or command-sensitive). It is a monitoring app,
I do need to be informed of any event in realtime (by “outputting” to
the console) while not messing up my input (or messing it up the least
possible :wink: )

I hope I made myself a little clearer.

But I suppose you’re right. I’ll try building of a single-threaded-IO
based architecture. Thinking of it, maybe callback procedures may
help…

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs