static current session variable

Neil Williams linux at codehelp.co.uk
Tue Aug 23 15:37:24 EDT 2005


On Tuesday 23 August 2005 12:12 am, Derek Atkins wrote:
> >> The static variable is in the data portion of the
> >> library, not the text portion of the library.  The data portion is
> >> copy-on-write cache, so when the PROCESS makes a change, it will
> >> overwrite the process-specific copy-on-write version of the variable.
> >
> > So each process, each application, has it's own implementation of
> > the statics that are defined in the library. Yes? That explains what
> > I saw.
>
> Effectively, yes.  It's not really an implementation per se.  Each
> process has it's own copy of the variable.  The variable gets its
> initial value from the .so, but the "writes" to the variable are done
> in the local process space, not in the "shared" space.

Right, thanks. 

> I can't see how you could have incompatible objects, unless you have
> two objects that share the same "name".  But that's effectively the
> same problem you have when you have two source files that have the
> same exported API function name.  It just doesn't work -- the linker
> will fail because of the duplicate names.  The solution is to make
> sure everything has a unique name.

OK.

> >> New code shouldn't use static variables for data context.
> >> (Process context is okay, like those module/object lists).
> >
> > Hmm. Is that assuming that each process has to live with it's set of
> > registered objects and that one process running with two
> > incompatible sets of objects will not be supported?
> >
> > I can't think of a use for that right now, I'm just curious.
>
> I'm not sure how you could have "two incompatible sets of objects"...

It was a name collision that I had in mind.

> > Yes. Can't we solve for just this problem by moving the static from
> > QOF into a different Gnucash C file? Wouldn't that create two
> > instances of the static, one in each gnucash application window? If
> > they were two processes, not one process with two threads, wouldn't
> > that work?
> >
> > Simply reverse the line in engine/gnc-session.h:
> > #define gnc_get_current_session qof_session_get_current_session
>
> I think that yes, that might solve this particular problem..

OK, I'll look at that.

> > Getting the session has just been the way to get the book. When you
> > don't have an instance to give you the book, maybe what we need is a
> > QofBook pointer in something like GncMainWindow that can serve as a
> > context? It doesn't have to be the same context for all.
>
> That presumes you have access to the GncMainWindow.  There are some
> APIs that don't have that, either.  But in general, yes, we would need
> to extend all APIs to have _some_ context object from which you can
> derive the Session, Book, or whatever.  But that's for another day.

Agreed - thanks for explaining.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050823/0d23547c/attachment.bin


More information about the gnucash-devel mailing list