[plt-scheme] Mred, exiting, and deamond threads

(yield (make-semaphore))

The original event never terminates, and all other events are handled 
on the nested call to yield. You can then actually exit with (exit), or 
by posting to the semaphore.

Robby

On Jan 29, 2004, at 9:02 PM, Guillaume Marceau wrote:

> Ok. That clears that up.
>
> Now, is there a way to prevent mred from quitting when the initial 
> thread returns and I have no widgets?
>
> My program instantiate a number of dispatchers threads, and these 
> threads react to network messages. Sometimes they put up gui widget, 
> and sometimes they don't.
>
> Right now, if the network thread do not put up guis, I have to 
> manually add the line :
>      "(thread-suspend (current-thread))"
> at the end of my main, otherwise mzscheme exits. Inversely, I have to 
> manually remove the line if the daemon thread do put up guis, 
> otherwise the guis have their event stream cut off.
>
>
>
> Robby Findler wrote:
>>  For list-related administrative tasks:
>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>> Defaultly, code that runs in mred is running on the eventspace's 
>> event handler thread (not on a thread that was started with 
>> `thread'). So, the code you run (say the body of those modules below) 
>> is treated as a callback in the initial eventspace. MrEd exits when 
>> there are no more callbacks to run in the initial eventspace. That 
>> is, when there are no more frames and no running event% objects (and 
>> there isnt' a callback running at the moment).
>> This is the eventspace handler thread's equivalent of "completion" 
>> and this test isn't really used anywhere else in the system.
>> Suspending the eventspace's thread means that you've suspended that 
>> one callback, so that callback hasn't finished (so mred doesn't 
>> exit). Gui widgets "break" because you've frozen the handler thread 
>> (so it's not so much the widget that broke as it was the callback you 
>> wrote that was broken :).
>> Robby
>> On Jan 29, 2004, at 6:44 PM, Guillaume Marceau wrote:
>>>   For list-related administrative tasks:
>>>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>>
>>>
>>> What is the rule that gouvern when mred exits, with respect to 
>>> threads?
>>>
>>> This program exits:
>>>
>>>   (module test mzscheme
>>>     (thread (lambda () (let loop () (display "hello\n") (sleep 1) 
>>> (loop)))))
>>>
>>>
>>> But this one doesn't:
>>>
>>>   (module test mzscheme
>>>     (thread (lambda () (let loop () (display "grettings\n") (sleep 
>>> 1) (loop))))
>>>     (thread-suspend (current-thread)))
>>>
>>>
>>> Neither does this one:
>>>
>>>   (module test mzscheme
>>>     (require (lib "class.ss")
>>>              (lib "mred.ss" "mred"))
>>>
>>>     (define frame (instantiate frame% () (label "GUI") (height 150) 
>>> (width 200)))
>>>     (send frame show #t)
>>>
>>>     (instantiate message% () (label "g'evening" frame))
>>>
>>>     (thread (lambda () (let loop () (display "g'evening\n") (sleep 
>>> 1) (loop)))))
>>>
>>>
>>> Also, if I combine the two, gui widjets break:
>>>
>>>   (module test mzscheme
>>>     (require (lib "class.ss")
>>>              (lib "mred.ss" "mred"))
>>>
>>>     (define frame (instantiate frame% () (label "GUI") (height 150) 
>>> (width 200)))
>>>     (send frame show #t)
>>>
>>>     (instantiate message% () (label "welcome" frame))
>>>
>>>     (thread (lambda () (let loop () (display "welcome\n") (sleep 1) 
>>> (loop))))
>>>     (thread-suspend (current-thread)))
>>>
>>> After the call to thread-suspend, the gui no longer refreshes.
>>>
>>>
>>>
>>>
>>> -- 
>>> "The thing I remember most about America is that it's silly.
>>>  That can be quite a relief at times."  -- Thom Yorke, Radiohead
>>>
>>> - Guillaume
>
>
>
-------
SII(SII)
&
((lambda (x) (x x)) (lambda (x) (x x)))