Petter Reinholdtsen wrote:
> I've been trying to compile the new GC implementation, and noticed
> that it requires glib's queue operations to function. I don't think
> that is required. Our qop.h now has (a slow) DEQUEUE() which together
> with the fast ENQUEUE() gives us a full queue implementation. I
> suggest using them for now, instead of making japhar depend on yet
> another external library.
yeah, but the gqueue stuff doesn't act in quite the same fashion as ours
does.
> I have not started on the changes, as Chris sounded like he was about
> to start working on this part.
yeah, i've got some outstanding changes in my tree.
> I'm not completely sure that my feelings in this matter are well
> funded, but thought it was best to air them to get different views.
> Should we reinvent the weel to avoid adding more to the dependency
> list?
>
> If we start using glib queues, I think we should remove qop.h
> completely, and use it all over. BTW, I was unable to find the glib
> queue operation in my v1.1.5. Which version has them?
i found it in version 1.3
the glib queues are a bit faster than our queues, since they maintain two
pointers (head and tail), and you can pop from either.
i wouldn't have a problem with using them, but i don't want to pull in
all of glib just for this one data
structure. perhaps we can plunder glib a bit and take just the gqueue.c
and remove its dependence on glists and just use that.
also, our queue stuff (the modified gqueue stuff) will need to be
threadsafe (especially in the case of the ksgc use of it.)
xtoph
