I'm using libcall() to implement a plugin which corrects parentheses on every edit (TextChangedI/TextChangedP). It works well, is snappy, and so forth, but it seems to make Vim SIGABRT "at random". I tracked down the issue, and it seems that on Mac OS X (at least), if a dylib uses any thread local variables, a tlv key is allocated (inside dlopen()) every time the library is loaded. These don't appear to ever go away, and there is a maximum number allowed per process. dlopen() calls abort() if we run out.
Vim calls dlopen(), dlsym(), then dlclose() for *every* libcall() invocation. I'm currently plotting a work-around involving referencing the library from inside itself so it will never be closed (Vim's dlclose() call won't be "balanced"). But I wonder whether and how to make Vim able to keep a library around. Possible ideas: 1. A new libload()/libunload() pair of calls, wrapping dlopen()/dlclose() or the Windows equivalent. A plugin can call libload() first, which will keep the library in memory. 2. A new, optional parameter to libcall(), saying it's OK to keep the library around, and maybe it is GC'd later? 3. ??? Thanks, -Jason -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
