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