On Tue, Jul 09, 2013 at 06:58:32PM +0100, Neil Roberts wrote:
> Bill Spitzak writes:
>
> > Maybe it can abort if ...read_events() is called after an error was
> > encountered. Then bad toolkits will exit, while ones that check for the
> > error state can do something intelligent.
>
> This soun
On Tue, Jul 09, 2013 at 02:10:45PM +0100, Neil Roberts wrote:
> If EOF is encountered while reading from the Wayland socket,
> wl_display_read_events() will now return -1 so that it will be treated
> as an error. The documentation for this function states that it will
> set errno when there is an e
Bill Spitzak writes:
> Maybe it can abort if ...read_events() is called after an error was
> encountered. Then bad toolkits will exit, while ones that check for the
> error state can do something intelligent.
This sounds like a nice idea but it might go a bit wrong if there are
orthogonal bits
> the only thing that confused me was the past tense sentence […]
Ok, that sounds sensible. Here is an updated patch.
> However we'd have to change every client / toolkit and so using a
> fatal display error is nicer since the toolkits should already be
> handling that.
Well, that would be ideal
Hi Neil,
On 9 July 2013 14:10, Neil Roberts wrote:
> If EOF is encountered while reading from the Wayland socket,
> wl_display_read_events() will now return -1 so that it will be treated
> as an error. The documentation for this function states that it will
> set errno when there is an error so i
If EOF is encountered while reading from the Wayland socket,
wl_display_read_events() will now return -1 so that it will be treated
as an error. The documentation for this function states that it will
set errno when there is an error so it additionally makes up an errno
of EPIPE.
If we don't do th
