[sheepdog] [discuss v2] Design of Libsheepdog

[Liu Yuan]

On Thu, Jul 25, 2013 at 09:28:42AM +0800, Kai Zhang wrote:
> 
> On Jul 25, 2013, at 5:43 AM, Joseph Glanville <joseph at cloudscaling.com> wrote:
> 
> > On Wed, Jul 24, 2013 at 5:23 PM, Liu Yuan <namei.unix at gmail.com> wrote:
> >> On Wed, Jul 24, 2013 at 04:12:46PM +0900, MORITA Kazutaka wrote:
> >>> At Tue, 23 Jul 2013 17:20:10 +0800,
> >>> Kai Zhang wrote:
> >>>> 
> >>>> On Jul 23, 2013, at 5:13 PM, MORITA Kazutaka <morita.kazutaka at lab.ntt.co.jp> wrote:
> >>>> 
> >>>>> We already have a tiny event library (lib/event.c).  Your plan don't
> >>>>> use it at all, or supports it as an option?
> >>>> 
> >>>> We can support it as an option.
> >>>> However, I think user would be more familiar with libev, libevent and libuv.
> >>> 
> >>> The user needs to be aware of the implementation of the underlying
> >>> event library?  I'm not sure it's a good design for now, but want to
> >>> see the implementation for further discussion.
> >>> 
> >> 
> >> I think we can build higher sync APIs that make use of async APIs underneath
> >> with a selected event library. Advanced users can make use of async APIs with
> >> their own selected event library.
> > 
> > Yes this is the prefered approach, this way if you embed the library
> > in an application you can integrate it into the applications event
> > loop.
> > 
> 
> Does this mean that even if the users only use sync API, they still have to provide an event loop?
> 

I think we can choose a default event loop mechanism for sync API. our lib/event.c
is a good candidate for it, because it doesn't need extra library dependency and
easy to hack.

Thanks
Yuan