Bill Spitzak writes:
> I think that rather than some trick to fool glib into making the poll
> return immmediately, calling dispatch_pending in a loop until it returns
> false will work better, and the poll can be called normally.
I wouldn't consider this to be a ‘trick’. It's normal and docum
On 27 July 2013 19:28, Bill Spitzak wrote:
> I think that rather than some trick to fool glib into making the poll return
> immmediately, calling dispatch_pending in a loop until it returns false will
> work better, and the poll can be called normally.
Um, it's not a trick, it's exactly how GSour
I think that rather than some trick to fool glib into making the poll
return immmediately, calling dispatch_pending in a loop until it returns
false will work better, and the poll can be called normally.
If glib does not reliably call something before the poll (possibly
documented as something
On 07/27/2013 02:08 AM, Rob Bradford wrote:
On 27 July 2013 00:21, Bill Spitzak wrote:
+ device = output->device;
fbdev_output_destroy(base);
Are you sure this does not free the memory that is now at *device?
Maybe I missed something - can you point me at the
Bill Spitzak writes:
> You can call dispatch_pending "last", ie as part of the dispatch
> function. It's in a loop, so doing something at the end of the loop is
> the same as doing it at the start.
I don't think that will work for GLib because you can't really control
the order of the dispatch f
On 27 July 2013 00:21, Bill Spitzak wrote:
>> + device = output->device;
>> fbdev_output_destroy(base);
>
>
> Are you sure this does not free the memory that is now at *device?
Maybe I missed something - can you point me at the code which makes
you think it does? My
