Use of complete GList functionality? Change to GSList?

Derek Atkins warlord@MIT.EDU
04 Mar 2001 17:00:47 -0500


Dave Peticolas <dave@krondo.com> writes:

> GLists are allocated with the glib memory routines. You cannot mix
> them with the libc routines. Any engine structures that the RPC
> backend creates needs to use glibc memory routines if they are used
> for that in the engine. Is RPC going to be able to handle that?

Unfortunately no.  I can't plug in a special malloc into RPC.  Memory
get's alloc'ed out of libc (which is where the general XDR routines
live).  Oh well, I was hoping to avoid the double-copy. I'll just have
to copy and fix everything on the other end.  At least I can still
pass a GList _into_ the RPC engine (casting a GList to a GSList will
"work" for read-only operations).  I just can't expect to get one out
on the other end :)

> > The problem is that while RPC can handle a linked list, at cannot
> > handle a doubly-linked list.  Therefore, anything that is using a
> > GList just plain loses in terms of building an RPC structure that
> > matches.  If, however, we used GSLists, then I could easily build an
> > RPC equivalent.
> 
> Why? If it's just for storage you can store it as a singly-linked
> list and fix it up when you load it.

Well, I was thinking that the RPC-server would interface back into the
GNC Engine.  This means I have to do duplication of information on
both sides of the RPC interface.  For example, I think I can pretty
much transfer a Query object (or at least the list of QueryTerms)
without many problems (the only problem of course being that I can't
transmit the Predicate function pointers).  However, I can't get a
_real_ GList (or QueryTerms) on the receiving end, because I can't
transmit a real GList, so I have to still rebuild the QueryTerms
before I hand it off to the engine.

This is also an issue on the client side.  If you're going to pull
down, say, 1000 transactions, I now need to pull them down (allocating
the memory within the RPC interface), and then allocate the same
amount of memory a second time (from glib), copy the information from
the RPC-allocated memory into the glib-allocated memory, and then free
the RPC-allocated memory.  Worse, I have to do a lot of this copying
on the server side, too, to copy the data from the internal structure
to the RPC structure.

I'm trying to make the structures look as similar as possible, but in
the end I don't think I'll be able to avoid this.  I suppose I'm
already going to have to do this anyways, but there are some places
where it would be nice to not have to do the duplication on _both_
sides.

> dave

-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@MIT.EDU                        PGP key available