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: >=20 > > Expect the API to break frequently/often for the time being, as it = is still > > in very early stages of development. >=20 > I=E2=80=99ve had a quick look at the library so far, and have a few = remarks. >=20 > 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). >=20 >=20 > 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=E2=80=99s easy. If they want one = libifc handle per thread that=E2=80=99s also easy. >=20 > 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. >=20 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); =E2=80=A6 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 =E2=80=98struct libifc_handle; typedef struct libifc_handle = libifc_handle_t;=E2=80=99) you can get away with changing the size or = contents of the struct without breaking any of the users. (Because they=E2=80=99ll only have a pointer to keep track of, the size = of the object it points to doesn=E2=80=99t 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>