SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] New to sctplib / impl. without glib?


Chronological Thread 
  • From: Carsten Fuchs <CarstenFuchs AT T-Online.de>
  • To: Thomas Dreibholz <dreibh AT iem.uni-due.de>
  • Cc: sctp-discussion AT sctp.de
  • Subject: Re: [SCTP-Discussion] New to sctplib / impl. without glib?
  • Date: Tue, 05 Feb 2008 16:01:53 +0100
  • List-archive: <http://lists.franken.de/pipermail/sctp-discussion>
  • List-id: SCTP Discussions <sctp-discussion.sctp.de>

Hi,

Thomas Dreibholz wrote:
On Freitag, 1. Februar 2008, Carsten Fuchs wrote:
[...]
Well, I was wondering what your plans wrt. glib are.
Are you planning to get rid of it?

Since glib is already installed on almost every Linux/FreeBSD/... system, I have never thought about replacing it. However, it should not be very difficult to do this. Writing a wrapper providing GList, GArray and the type definitions should already be sufficient. So, if you write such a wrapper, we could integrate it.

Thank you very much for your reply!
I tried several approaches for a wrapper over the weekend, but was not entirely satisfied with any of them.

The big question is, how much/many changes/inconveniences/trouble would you accept in a wrapper to still integrate it with the "official" sctplib?

[1] Personally, I'd just rename all *.c to *.cpp and replace the GArray with std::vector<> and GList with std::list<>.
[2] Another approach was to keep the GArray and GList interfaces and reimplement them with malloc() and free(), forgoing the allocation (speed) optimizations in the glib implementation. Another downside here is the introduction of new bugs with the new code.

Both of these approaches work for me just fine, but I was wondering if you'd
accept either?

Obviously, whatever kind of wrapper I implement, I'd enjoy the work a lot more if it was included with the official sctplib, because then other people would benefit as well, plus I'd safe myself from patching new releases of sctplib over and over again.
(Alternatively, has somebody else done this before on Windows with a compiler
newer than VC++ 6??)

So... give some advice please! What are my options for writing a patch that gets both rid of glib *and* has a change of being integrated *and* meets the demands wrt. speed and stability?

Many thanks and best regards,
Carsten



--
Ca3D - Engine http://www.Ca3D-Engine.de
Carsten Fuchs http://www.Ca3D-Engine.de/c_Carsten.php




Archive powered by MHonArc 2.6.19+.

Top of page