[comp.windows.news] bindkey process with interest hangs lwp at exit time?

paul@ppgbms (Paul Evan Matz) (12/05/89)

Was wondering if anyone out there has had a problem with application
light weight processes being hung at exit time if "bindkey" was used to
bind a piece of NeWS code to a particular key?  We are experiencing the
following:  an application uses the bindkey utility.  Seems to work
just fine;  The code, bound to the key in question, runs as expected
when the key is pressed.  Then, when trying to exit, the lwp who called
bindkey is hung until the key is pressed.  If the key is pressed, the
lwp exits normally.

Looking at the UI.ps code, it appears that the lwp, created to be interested
in the key, is created with a different lwp group:

        /bound_keys_proc {
            newprocessgroup
            createevent dup begin
            /Name bound_keys def
            /Action /DownTransition def
            /Exclusivity true def
            /Priority 3 def
            end expressinterest
            { awaitevent } loop
        } fork def

What kills this guy when his creator is gone?  Is that what causes the
creator to be hung?

Hope this isn't too much old hat, being a NeWS 1.1 problem, and all.

Thanks (wishful thinking)
_____________________________________________________________
|Regards,                           One Campus Drive        |
|Paul Matz                          PPG Biomedical Systems  |
|914-741-4685                       Pleasantville, NY. 10570|
-------------------------------------------------------------
path ppgbms!moe!paul@philabs.philips.com

sjs@spectral.ctt.bellcore.com (Stan Switzer) (12/05/89)

In article <22006@ppgbms.UUCP> paul@ppgbms (Paul Evan Matz) writes:
> Was wondering if anyone out there has had a problem with application
> light weight processes being hung at exit time if "bindkey" was used to
> bind a piece of NeWS code to a particular key? ...
> Looking at the UI.ps code, it appears that the lwp, created to be interested
> in the key, is created with a different lwp group:
> 
>         /bound_keys_proc {
>             newprocessgroup
>             createevent dup begin
>             /Name bound_keys def
>             /Action /DownTransition def
>             /Exclusivity true def
>             /Priority 3 def
>             end expressinterest
>             { awaitevent } loop
>         } fork def

Of course it is impossible to tell what is going on without looking at
your code.  Nevertheless, here's a guess:

The first time you bind a key, the proc you quote above gets started.
Unfortunately, when it runs with a copy of the invoker's user
dictionary and stack contents.  If there is anything in your stack or
userdict that you need garbage-collected at termination, you will be
out of luck.  The "newprocessgroup" is bindkey's protection against
your termination.  Unfortunately, you have no protection against
bindkey's non-termination.

If this is your problem, try this:

    /safebindkey { % key [proc|str] => --
	{ % fork
	    countdictstack 1 sub { end } repeat      % clear dict stack
	    count 2 roll count 2 sub { pop } repeat  % clear oper stack
	    bindkey null
	} fork waitprocess pop
    } def

Ideally, bindkey would have done this internally, saving you the
trouble.

Stan Switzer  sjs@bellcore.com