Jamie Zawinski writes:
I assume there's still nobody actually working on the OSX
of xemacs, but just for posterity I thought I'd point out that
there seems to be a mach port leak somewhere.
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.
I use shell buffers a lot, so that's a likely suspect.
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
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.
XEmacs-Beta mailing list