On Wed, 23 Jan 2019 13:34:08 +0100
Gergely Polonkai <gerg...@polonkai.eu> 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

Reply via email to