Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!bellcore!spectral!sjs
From: sjs@spectral.ctt.bellcore.com (Stan Switzer)
Newsgroups: comp.windows.news
Subject: Re: bindkey process with interest hangs lwp at exit time?
Keywords: bindkey NeWS 1.1
Message-ID: <18470@bellcore.bellcore.com>
Date: 5 Dec 89 14:13:15 GMT
References: <22006@ppgbms.UUCP>
Sender: news@bellcore.bellcore.com
Reply-To: sjs@bellcore.com (Stan Switzer)
Distribution: na
Organization: Bellcore
Lines: 43

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