[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