static current session variable

[Derek Atkins]

Neil Williams <linux at codehelp.co.uk> writes:

>> > Should the static current_session variable be static in qofsession.c?
>>
>> Techincally... no.
>
> I understand now, thanks. "It's too much to change now but don't write any new 
> code that way".

Pretty much..  Although eventually I think we SHOULD change it..  But
not right now.  Granted, this will be harder once QOF is external.

> I appreciate how much work it would be to have a common context - it took a 
> while to do that just for the merge routines.
>
> HOWEVER, I have done exactly this in the CLI. Each CLI has it's own qof-data 
> context that explicitly includes (currently) two sessions and that may even 
> be increased to possibly three or even a GList of possible sessions. I 
> inadvertently used qof_session_set_session in pilotqof but that is easily 
> removed because the context already exists.

Yea, new code shouldn't depend on the current_session in QOF.  The CLI
having its own session context is definitely the right way to go.

> Unfortunately, I haven't been so circumspect in my GUI GnuCash code:
> gnome/dialog-chart-export.c contains a context already in use but
> doesn't put the session into the context! Duh! That's an easy one to
> fix. Same with gnome/druid-merge.c.

Haven't looked at that code, so I don't know.  You don't necessarily
need to remember the QofSession per se.  If you have a Transaction
then you can get to the Book, and from the Book you can get to the
Session..

> I suspect that a lot of uses of current_session also have a usable context 
> nearby.

Well, anytime you have a QofInstance you have a session..  But there
are a number of APIs that don't take a Qof<something> as an argument.

>> Two PROCESSES?  No.
>
> Now this is where I wanted clarification.
>
>> 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.

>> > What about the static registered object hash table in qofclass.c ?
>> > static GHashTable *classTable = NULL;
>> > and the modules_list in qofobject.c:
>> > static GList *object_modules = NULL;
>>
>> These are okay to remain static objects in the library for the above
>> reason.
>
> Shouldn't they eventually be made part of the same overarching context? The 
> session would be a good start - each session to have it's own registered 
> objects, it's own list of books, it's own set of backends and should be made 
> thread-safe. After all, as far as QOF is concerned the objects are just 
> another type of data.

No.  These are plugging in code, not data.  You're not plugging in
objects, here -- you're plugging in classes!  You do NOT want to have
the class in a particular session -- you want the whole process to
have access to the class.  It makes no sense to do it any other way.

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.

The same solution is true with different set of Qof Classes.  Make
sure each class has a unique name.

> That would need some changes in QOF to create new books within the same 
> session rather than, as now, creating a whole new session. It is a big job.

I think that's a different issue.

>> 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"...

>> The 
>> problem is that you cannot have two threads in the same process that
>> have different sessions.  For example, wouldn't it be nice to have one
>> gnucash app that has two books open at the same time in two top-level
>> windows?
>
> 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..

[snip]

> 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.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available