Date: Tue, 12 Apr 2016 16:23:16 +0200 From: Kristof Provost <kp@FreeBSD.org> To: Marie Helene Kvello-Aune <marieheleneka@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: libifconfig: Initial code available, looking for feedback Message-ID: <24C6C827-DD53-447B-B9EB-90E73347DC1A@FreeBSD.org> In-Reply-To: <CALXRTbe14nzRt15P_Tn4tUsgDPmEwJ_bHHVMMakzHfas2OYdWg@mail.gmail.com> References: <CALXRTbfxxf%2BbUev8sBoJEOfR41ZsLnB35i%2B4G_2Bp=j-eVVJQQ@mail.gmail.com> <C6D42B75-5C78-45F1-8AFD-3CD8D2BF2E1D@FreeBSD.org> <CALXRTbe14nzRt15P_Tn4tUsgDPmEwJ_bHHVMMakzHfas2OYdWg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 12 Apr 2016, at 16:09, Marie Helene Kvello-Aune <marieheleneka@gmail.com> wrote: > > > Expect the API to break frequently/often for the time being, as it is still > > in very early stages of development. > > I’ve had a quick look at the library so far, and have a few remarks. > > It might be better to have an explicit (opaque to the library user) handle > to contain both the error state (libifconfig_errstate) and the open sockets (sdkeys). > This would go a long way in making the library thread-safe (because users can now > rely on their error state not getting clobbered by another thread). > > > Good idea. Adrian Chadd mentioned something like this off-list as well, and I still haven't quite decided how to implement it. I have considered looking into implementing this similar to how the global 'errno' variable is implemented, but I haven't actually researched how to do this yet. Iirc. errno is implemented using a thread-local variable. /usr/include/sys/errno.h #defines it to (* __error()), which is implemented in lib/libc/sys/__error.c and lib/libthr/sys/thr_error.c That seems both complicated and needlessly restrictive. The second option gives all freedom to implementors. If they want one libifc handle protected by a mutex that’s easy. If they want one libifc handle per thread that’s also easy. > > I'm currently leaning towards having a libifconfig_state_create() (or similarily named) method which retrieves an appropriate struct for the calling application to pass into the library methods. > Yeah, I was thinking something along the lines of this: libifc_handle_t* libifc_open(); void libifc_close(libifc_handle_t *h); int libifc_set_mtu(libifc_handle_t *h, const char *name, int mtu); … Possibly also: int libifc_get_error(libifc_handle_t *h); If the definition of libifc_handle_t is kept opaque (so the headers only have ‘struct libifc_handle; typedef struct libifc_handle libifc_handle_t;’) you can get away with changing the size or contents of the struct without breaking any of the users. (Because they’ll only have a pointer to keep track of, the size of the object it points to doesn’t matter to them.) Regards, Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24C6C827-DD53-447B-B9EB-90E73347DC1A>