On Thu, Dec 5, 2013 at 4:16 AM, Chris Vine <ch...@cvine.freeserve.co.uk> wrote: > On Thu, 5 Dec 2013 03:06:59 +1100 > Chris Angelico <ros...@gmail.com> wrote: >> See how much effort goes into >> making sure everything's thread-safe? [None], because this >> isn't even threaded - though it will happily handle any number of >> simultaneous clients. > > And to make the point for David, you can do the same in the C > GTK+/glib libraries, by abandoning threads and instead setting up an > asynchronous watch on the socket using a GIOChannel with > g_io_channel_add_watch(). > > However, even better than that is to use gio's high level > GSocketListener and GSocketConnection, and read on the contained > GInputStream asynchronously using g_input_stream_read_async().
I'm not aware of the details of that, as I've never used GTK in C, but it doesn't surprise me that there are convenient ways to do this. Socket handling is just such a common thing to do! Though there might not be quite such easy solutions for other tasks, I'm sure there'll be some way of doing it - after all, not every platform even supports threads. I could do the Pike example as threaded, though; it'd still be way cleaner than the C version, because I can simply pass a string around - notice how my read_callback is simply given a string as an argument, same as you might be given an integer in C. In most modern high level languages (including both Python and Pike, and plenty of others), strings, arrays, mappings, and so on are all first-class objects. No fiddling with memory (de)allocation. Ever so much easier. Under the covers, they're usually all stored on the heap, and probably refcounted. ChrisA _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
