On Wed, 23 Jan 2019 13:34:08 +0100 Gergely Polonkai <gergely@xxxxxxxxxxx> wrote: > Hello, > > yes, the first two bytes of the response is the message length. If i > explicitly read exactly two bytes (to get the message length) and then > explicitly read that many bytes to get the response, i’m fine. > > What is not working as i expected is the polling. I thought that if i > > * set the socket to non-blocking (g_socket_set_blocking()) > * create a source for the socket with the G_IO_IN and G_IO_PRI flags > (inbound data + priority inbound data, although i’m pretty sure priority > inbound doesn’t happen on this protocol) > * set a callback function with g_source_set_callback() > > then my callback will be called whenever there is data available. At least > that’s what i’d do if i’d be using plain Linux sockets, using > select()/poll()/epoll(). glib file descriptor polling works in the way you describe - on unix-like systems it is a front end for poll(). Is your callback returning TRUE or G_SOURCE_CONTINUE? If it isn't, after the first read the source will be removed. I know the documentation says that there is no need to apply the G_IO_HUP flag but I would still add it and see if it makes a difference, should an end-of-file event be missing. _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
