scm_shell in C-Thread - Quit vs. Terminal Corruption

scm_shell in C-Thread - Quit vs. Terminal Corruption

[vimml]

Hi Schemers!

I'm rather new to using guile, so please pardon if my question is more
trivial than I think it is :)

I have a graphics application (OpenGL) that spawns a thread which
executes scm_shell(). This way I can use the terminal to query various
information about the rendering. The program is usually exited by
pressing <ESC> in the graphics window.

I found that I am unable to cleanly terminate both threads (acutal
application and guile). When I enter 
	(quit)
in the terminal scm_shell calls exit(), which does not care much for my
application cleanup. When I press <ESC> the guile thread get aborted
when the application terminates.

To couple the guile-thread with the termination of my program I came up
with starting a new thread in my scheme initialization which checks if
the scheme-side should terminate. The pattern is shown in the following
code, typed into the guile interpreter:

guile> (define other-thread-wants-to-quit #f)
guile> (define (my-thread) (if other-thread-wants-to-quit (begin (display "going home")(newline)(quit))) (sleep 1) (my-thread))
guile> (call-with-new-thread my-thread)
guile> (set! other-thread-wants-to-quit #t)
guile> going home

When I run this it terminates the guile session, but also destroys my
terminal. After guile returned the prompt is visible, but the characters
thereafter are black on black, and hitting return does not break the
current line. Hm, hard to describe, look at this:
Hitting return three times yields:
shellprompt ~ $ shellprompt ~ $ shellprompt ~ $

To summarize, my questions are:
- Is there a better way to tell the scheme-thread to terminate?
- Why does the code given above mess with my terminal?
- What can I do to avoid it?

Thanks in advace, and have a nice weekend :)
	Kai

Re: scm_shell in C-Thread - Quit vs. Terminal Corruption

[Linas Vepstas]

2009/10/16  <vimml@selgrad.org>:

> application and guile). When I enter
>        (quit)
> in the terminal scm_shell calls exit(), which does not care much for my
> application cleanup.

wouldn't atexit() solve this problem?

--linas

Re: scm_shell in C-Thread - Quit vs. Terminal Corruption

[Linas Vepstas]

2009/10/16  <vimml@selgrad.org>:
>
> Hitting return three times yields:
> shellprompt ~ $ shellprompt ~ $ shellprompt ~ $

I didn't quite understand everything, but -- saying
"stty sane" should fix this problem.

I'm not sure what stty sane does, its some sequence of
calls to tcsetattr I guess.

strace reports that its   opost isig icanon echo ...

so you should use atexit, and have the atexit routine do the
tcsetattr  -- right?

--linas

Re: scm_shell in C-Thread - Quit vs. Terminal Corruption

[Ludovic Courtès]

Hi,

Linas Vepstas <linasvepstas@gmail.com> writes:

> 2009/10/16  <vimml@selgrad.org>:
>>
>> Hitting return three times yields:
>> shellprompt ~ $ shellprompt ~ $ shellprompt ~ $
>
> I didn't quite understand everything, but -- saying
> "stty sane" should fix this problem.

Alternatively, reset(1) will return the terminal in a normal state.

Thanks,
Ludo’.

Re: scm_shell in C-Thread - Quit vs. Terminal Corruption

[Ludovic Courtès]

Hi,

vimml@selgrad.org writes:

> - Is there a better way to tell the scheme-thread to terminate?

You could use a condition variable (info "(guile) Mutexes and Condition
Variables").

> - Why does the code given above mess with my terminal?

I don’t know.  This happens sometimes with ncurses applications that
fail to reset the terminal state upon exit, or generally applications
that use tcsetattr(3) without the ‘ECHO’ flag (e.g., command line
programs asking for a password).

Thanks,
Ludo’.

Re: scm_shell in C-Thread - Quit vs. Terminal Corruption

[kai.selgrad]

Hej linas,

thanks for your reply.

> > application and guile). When I enter
> >        (quit)
> > in the terminal scm_shell calls exit(), which does not care much for my
> > application cleanup.
> wouldn't atexit() solve this problem?
Yes, you're right. atexit() would solve this problem. Didn't really
think about that before... hm :)
Sadly, the otherway around is much more common (pressing ESC in the
application window, thus terminating the actual application thread).

Well, thanks for this one :)
	Kai

Re: scm_shell in C-Thread - Quit vs. Terminal Corruption

[vimml]

Hej,

thank you both :)

> >> shellprompt ~ $ shellprompt ~ $ shellprompt ~ $
> >
> > I didn't quite understand everything, 
Ok, that was a little cryptic, just to clarify myself, I meant:
shellprompt ~ $ echo "hello"
hello
shellprompt ~ $ guile myscript.scm
<output>
shellprompt ~ $

At this point hittig return does no longer break lines, thus resulting in 
shellprompt ~ $ shellprompt ~ $ shellprompt ~ $ 

I hope it is clearer now :)

> > "stty sane" should fix this problem.
> Alternatively, reset(1) will return the terminal in a normal state.
I was actually hoping to find out how to avoid the situation at all, but
knowing this the testing should be more convenient now :)

Kai.

Re: scm_shell in C-Thread - Quit vs. Terminal Corruption

[vimml]

Hej again :)

On 21:49 Fri 16 Oct     , Linas Vepstas wrote:
> so you should use atexit, and have the atexit routine do the
> tcsetattr  -- right?
Didn't know about this function. I think I will give it a try.

Do you have any idea why this is actually happening? I would expect
guile to properly reset my terminal settings (my application thread does
nothing with the terminal, so I this this is something guile oder
readline does). Correct me, if I'm wrong.

Thanks for your replies, all :)
	Kai

Re: scm_shell in C-Thread - Quit vs. Terminal Corruption

[Neil Jerram]

kai.selgrad@web.de writes:

> Hej linas,
>
> thanks for your reply.
>
>> > application and guile). When I enter
>> >        (quit)
>> > in the terminal scm_shell calls exit(), which does not care much for my
>> > application cleanup.
>> wouldn't atexit() solve this problem?
> Yes, you're right. atexit() would solve this problem. Didn't really
> think about that before... hm :)
> Sadly, the otherway around is much more common (pressing ESC in the
> application window, thus terminating the actual application thread).

Calling scm_shell() with no args means just that that thread will run
`(top-repl)' - whose definition you can see in boot-9.scm.  In other
words you could say that the default args are like `-c (top-repl)'.

`(quit)' means (throw 'quit ...), and the (top-repl) code handles this
by exiting its internal loop.  Then scm_shell() calls exit().

So, if you want something else to happen after `(quit)', such as waiting
for other threads to terminate and clean up, you just need to put code
for that in a procedure named, e.g. `wait-for-cleanup', and then call
scm_shell() with args `-c (begin (top-repl) (wait-for-cleanup)'.

(All in theory anyway, I'm afraid I haven't tested this!)

      Neil

Re: scm_shell in C-Thread - Quit vs. Terminal Corruption

[kai.selgrad]

Hej Neil.

On 16:05 Sun 18 Oct     , Neil Jerram wrote:
> Calling scm_shell() with no args means just that that thread will run
> `(top-repl)' - whose definition you can see in boot-9.scm.  In other
> words you could say that the default args are like `-c (top-repl)'.
> 
> `(quit)' means (throw 'quit ...), and the (top-repl) code handles this
> by exiting its internal loop.  Then scm_shell() calls exit().
> 
> So, if you want something else to happen after `(quit)', such as waiting
> for other threads to terminate and clean up, you just need to put code
> for that in a procedure named, e.g. `wait-for-cleanup', and then call
> scm_shell() with args `-c (begin (top-repl) (wait-for-cleanup)'.

That sounds pretty good, thank you! I think I should be able to get my
stuff working with this information. :)
I will give it a try this week.

	Kai.