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

[Rusty Russell]

Allan Ference <f.fallen45 at gmail.com> writes:

> Hey Rusty,
>
> Got a few questions if you don't mind:
> On Tue, Dec 4, 2012 at 2:14 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>
>>         /* Useful next functions. */
>>         /* Close the connection, we're done. */
>>         void next_close(struct conn *, void *arg));
>>
>> I'm not quite sure what this should do exactly, it may sound stupid but,
> is it supposed to close the conn specified next time activity comes through
> it?

Sorry, I was away...

        The idea was that every callback arranged a 'next' function:
this one is a little special, meaning we close the connection
immediately.

>> The best thing is that you could force the implementation into a
>> debugging sychronous mode, where conn_read_* and conn_write_* worked
>> synchonously, and conn_next immediately called the next function.  This
>> gives you a nice call-chain to see exactly what occurred.
>>
>> So the only part that's supposed to work asynchronously is the server,
> right?
> I also don't quite get the idea here, shall we make every incoming
> connections BLOCKING and not add it to the polling queue?!

Normally, when they call conn_next(), we just assign to connection->next
so we know what to call next time, and return (back to the main loop).

If we're debugging, conn_next() should invoke the main loop itself,
rather than returning.

But this is an optional feature which can be implemented afterwards...

Cheers,
Rusty.