[ccan] ccan: the psuedo "networking" module.

Rusty Russell rusty at rustcorp.com.au
Mon Dec 10 11:06:29 EST 2012


Allan Ference <f.fallen45 at gmail.com> writes:
> Hey rusty,
>
> Sorry for yestarday's email, I was drunk and somewhat clicked send when
> it's incomplete...

I do that when I'm sober :)

> So here's the idea:
>
>        struct io_service {
>                 struct sock_events *sevents;
>        };
>
>        /* ... your functions, new_listener() and so on */
>        /* Creates a thread */
>        void start_service(struct io_service *service);
>        /* Blocks until all polling is done.  */
>        void run_service(struct io_service *service);

As you inferred, I hid such structure behind the API: internally,
listeners and connections come down to very similar things.

There are two parts to the API:
1) The part where each function says explicitly what happens next, so
   it's easy to follow.  This is the bit I concentrated on.

2) The part where something drives it, eg. threads, epoll, select, gtk...
   This is important too, I just haven't thought about it as hard.

They might even be separate modules: the basic module might just provide
hooks and then you have to choose a backend module, eg, if we call the
module "serv" (I like short names):

        ccan/serv: the API I suggested.
                Also supplies hooks for the backends to register (you
                need one)

        ccan/serv/epoll:
        ccan/serv/select:
        ccan/serv/pthread:
        (others?)
                Different backends, you compile in one or more, and you
                get the "best" supported one...

Cheers,
Rusty.


More information about the ccan mailing list