On Mon, Oct 16, 2017 at 10:53:43AM -0400, Frediano Ziglio wrote:
> > -
> > - n = select(nfds, &readfds, &writefds, NULL, NULL);
> > - if (n == -1) {
> > - if (errno == EINTR)
> > - continue;
> > - syslog(LOG_ERR, "Fatal error select: %s", strerror(errno));
> > - break;
> > - }
> > + if (vdagent_init_async_cb(agent) == G_SOURCE_CONTINUE)
> > + agent->timer_source_id = g_timeout_add_seconds(1,
> > vdagent_init_async_cb, agent);
>
> Was thinking about this code.
> Maybe would be better to just register the function with
>
> agent->timer_source_id = g_timeout_add_seconds(0, vdagent_init_async_cb, agent);
If your expectations are that g_timeout_add_seconds(0, ...) is going to
trigger the callback right away, this is not necessarily going to work
as expected, see the last paragraph of
https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=3e3b37b672
« update_display_timer(0) schedules a timeout to be run with
g_timeout_add_seconds(0). However, g_timeout_add_seconds() schedules
timers with a granularity of a second, so the timeout we scheduled with
g_timeout_add_seconds() may fire up to 1 second later than when we
called it, while we really wanted it to fire as soon as possible.
Special-casing update_display_timer(0) and using g_timeout_add() in that
case avoid this issue. In theory, the race could probably still happen
with a very very bad timing, but in practice I don't think it will be
possible to trigger it after this change. »
Christophe
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel