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

[Rusty Russell]

Allan Ference <f.fallen45 at gmail.com> writes:
> On Tue, Dec 4, 2012 at 2:14 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
>> Allan Ference <f.fallen45 at gmail.com> writes:
>> Okay, though it seems to be kind of dead so Cc'ing it may not be of use
> but I've guessed it may be that you don't like checking e-mails.

Yes, the list is quiet, but it's good quality :)

>>         /* Listeners create connections. */
>>         struct listener;
>>
>> I don't quite get this one, you never use this variable \/

You're right, in the end my API didn't need it, so it'd be internal.

>
>>         /* One connection per client. */
>>         struct conn;
>>
>> Nor this one >_>

This one I used..

>> Your idea is nice, and I tottaly agree with you to be honest, I will try
> to rewrite it soon, just need some more time.

Of course.

>> The implementation can be done completely without threads, yet be fully
>> async.  Or another variant could use a thread per connection, so the
>> only user-visible synchronization would be for anything shared between
>> threads.
>>
> I don't think creating a thread per connection would be nice, the
> asynchronous methods do good job, however, for the server part sure we
> could leave that as a loop but consider something like so:

Agreed, an actual thread per connection would be dumb.  But for a
serious server you may want to use a pool of threads, but guarantee that
handlers for the same connection won't run in parallel.

Personally, I'd use antithread for such a server :)

> A graphical application (say a game or a chat client) want to handle GUI
> events (take something like gtk or Qt as an example, they require a
> gtk_main() and return application.exec())

I really dislike gtk: it tends towards "everything must be GTK".  But
looking at the documentation, it seems possible.

We'd need to deconstruct conn_loop().  In particular, we'd need hooks to
know when an fd is added (for g_io_channel_unix_new ()), closed
(g_io_channel_shutdown ()) or changed from read to write or vice-versa
(for g_io_add_watch ()).  Then we'd need something to handle events on a
single fd, eg:

        /* Return your_data. */
        void *(*conn_add_fd)(int fd, void *conn_data);
        void (*conn_del_fd)(int fd, void *conn_data, void *your_data);
        void (*conn_watch_fd)(int fd, void *conn_data, void *your_data,
                              int pollbits);

        void conn_fire(void *conn_data, int pollbits);

Given the number of allocations which gtk is like to do, it's not going
to be fast, but it'd probably work.

>> 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.
>>
>> Ah!  This is what I was thinking about just few days ago but I was too
> lazy to implement it, thanks for reminding me!
>
>> Of course, the names might need work, and the callbacks should be made
>> typesafe using ccan/typesafe_cb, but I'd love to use such a module!
>>
>> Cheers,
>> Rusty.
>>
>
> I'll do my best do improve it in the near future.

Good luck!
Rusty.