[sheepdog] [discuss v2] Design of Libsheepdog

[Joseph Glanville]

On Thu, Jul 25, 2013 at 12:36 PM, Liu Yuan <namei.unix at gmail.com> wrote:
> 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?

Why do you need an event loop for a sync api? sync api should just use
blocking sockets with the aim of being threadsafe.

>>
>
> 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