Jeff Collins <[EMAIL PROTECTED]> wrote:
> I've had a problem that I haven't had time to investigate. When a
> function from a Glib library calls a function in another GLib library
> _and_ vice-versa, the resulting circular dependency prevents the
> reference count in either library from reaching 1, and thus
> automatically cleaned up upon the termination of the application.
OK, this is easy to understand when you think a little deeper into it, but
unfortunately, this is a limitation in the GLib paradigm itself, not in its
implementation in the caller or the callee. I'm not the prc-tools design
architect or principal maintainer, and it's not my job to judge/improve the
GLib paradigm overall. All I'm doing is making a few enhancements on the caller
stub side only, to allow existing unmodified GLib PRCs to be called more
easily, from a wider variety of caller types (PalmOS-style shared libraries in
addition to apps), and with more control over the handling of pathological
cases.
> Also, to get my 7 libraries to work properly, I had to increase the
> table length to st_len = 12 in scrt0.c:AllocSaveTable(void). It might
> be better to increase the table length dynamically, instead.
OK, this is on the callee side only, so this can be done without breaking the
GLib caller-callee interface. Also since this change is on the callee side and
my changes are on the caller side, if I don't make this change but someone else
does independently, the two changes won't conflict or interact in any way.
So, will I make this change? Well, it looks non-trivial to me, so I would have
to treat it as a project, not as a one-evening hack, and JP Systems doesn't
need this at the moment, so I guess not...
--
Michael Sokolov 2695 VILLA CREEK DR STE 240
Software Engineer DALLAS TX 75234-7329 USA
JP Systems, Inc. Phone: +1-972-484-5432 x247
or +1-888-665-2460 x247
E-mail: [EMAIL PROTECTED] Fax: +1-972-484-4154
