Joachim (München) wrote:

> I am currently redesigning a program that shall accept input
> from both a GUI and from a terminal window that runs irb.
> 
> In reaction to the input, some output will be written to the
> terminal or/and some controls in the GUI will change.
> 
> I need help on the basic architecture of such a system.
> I have two rather vague ideas:
> 
> (1) Somehow run the irb terminal within the GUI's event loop?
> 
> (2) One thread runs the GUI, one thread runs the terminal?

IMHO you are better off writing a GUI that handles events from both the GUI
controls and the terminal window in a single thread. I say this for several
reasons. One is that Ruby threads within a single process aren't as
independent of each other as one might expect based on other languages --
indeed, IMHO the present Ruby thread facility is not very good. Another is
that multiple threads may represent a case of premature optimization,
before the simpler arrangement has been tried.

Does the irb terminal window accept input from a user, or is it fed data
from the program itself? If the former, it is highly likely that a
single-thread, user-event model would be best. Imagine a text editor
application, with a window for text entries and a set of controls and
menus. The user can type in the window or press buttons. There's no need
for multiple threads in this case.

Also, instead of using irb, have you considered using Kernel::eval? You
might get better results and more control using eval and similar processing
options than by running a copy of irb. This of course depends on the
purpose of your program, which you haven't discussed.

-- 
Paul Lutus
http://www.arachnoid.com