[issue] carbon xemacs mach port leak

Jamie Zawinski writes: Thanks for the report. No, there's nobody really working on Carbon, but Aidan does keep synching the port from the XEmacs trunk. I don't know if he bothers checking Choi's site though, or if we have Choi's most recent code. OK, I have a patch (attached at end), but I don't know why it would plug a leak in the shell buffers yet. Speculation welcome. I recommend that you try out the patch, it seems to help. No promises, obviously, since I don't know how the patch could work on shell-mode, testing is light, and I'm a little worried about changing the timer state from a timer callback. If you're watching the port usage in Activity Monitor, I'd appreciate knowing if you see any leakage. Details (mostly for the tracker): Before the patch, starting a fresh instance, starting a shell, and repeatedly `hg pull -u'ing the Carbon branch seems to consistently ratchet the port count up with each invocation. (It starts at 75, and seems to go up by 2 or 3 for most commands.) M-! does not seem to have the same effect though. I also seem to see a slow leak in the background, about 1 every five minutes. Working on the background angle, the Carbon implementation of itimers was leaking EventLoopTimers. Since all ELTs used are one-shot, I've patched the timer callback to remove the spent ELT. The way the timer code is implemented, mach port usage should be proportional to unexpired timers. With the patch, I don't see any background creep in mach port usage after 60 minutes. For reasons I don't understand yet, this patch also seems to have done wonders for the M-x shell leak as well. Hammering on `hg pull -u' has no visible effect on mach port usage. The first time I did a `cd' in the shell buffer I saw a bump in port usage, but repeated `cd's have had no further effect. Regards, Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta