Your MUA seems to spit out 6km long lines, which makes it very
hard to read when you also post code so I can't auto-reformat
on my end. I'll give it a go though.
On 03/20/2012 06:39 PM, Bill Spitzak wrote:
> I may not be understanding the problem, or maybe my assumption that
> the destruction of a
I may not be understanding the problem, or maybe my assumption that the
destruction of a "source" is not under Wayland's control.
My opinion is that "deferred deletion" is a bad idea. There may be other
objects being destroyed that destroy the source, and they rely on the
source actually disap
On 03/19/2012 09:44 PM, Bill Spitzak wrote:
>
>
> Jonas Ådahl wrote:
>> On Mon, Mar 19, 2012 at 7:10 PM, Bill Spitzak
>> wrote:
>>> Jonas Ådahl wrote:
>>>
That would not work because ep[i].data.ptr will already be
loaded with the source pointer pointing to deallocated memory.
It
On Mon, Mar 19, 2012 at 9:44 PM, Bill Spitzak wrote:
>
>
> Jonas Ådahl wrote:
>>
>> On Mon, Mar 19, 2012 at 7:10 PM, Bill Spitzak wrote:
>>>
>>> Jonas Ådahl wrote:
>>>
That would not work because ep[i].data.ptr will already be loaded with
the source pointer pointing to deallocated memor
Jonas Ådahl wrote:
On Mon, Mar 19, 2012 at 7:10 PM, Bill Spitzak wrote:
Jonas Ådahl wrote:
That would not work because ep[i].data.ptr will already be loaded with
the source pointer pointing to deallocated memory. It doesn't matter
if that particular source is free:ed and removed from the ep
On Mon, Mar 19, 2012 at 7:10 PM, Bill Spitzak wrote:
> Jonas Ådahl wrote:
>
>> That would not work because ep[i].data.ptr will already be loaded with
>> the source pointer pointing to deallocated memory. It doesn't matter
>> if that particular source is free:ed and removed from the epoll state
>>
Jonas Ådahl wrote:
That would not work because ep[i].data.ptr will already be loaded with
the source pointer pointing to deallocated memory. It doesn't matter
if that particular source is free:ed and removed from the epoll state
since it has already been triggered to dispatch. Another approach
w
On Mon, Mar 19, 2012 at 4:03 PM, Andreas Ericsson wrote:
> On 03/17/2012 09:39 AM, Jonas Ådahl wrote:
>> In order for users of the event loop to manipulate the state of it or
>> others, only one event may be processed per epoll_wait. When multiple
>> events are queued up and a user removes an even
On 03/17/2012 09:39 AM, Jonas Ådahl wrote:
> In order for users of the event loop to manipulate the state of it or
> others, only one event may be processed per epoll_wait. When multiple
> events are queued up and a user removes an event input source from an
> event loop from within a dispatch, if
In order for users of the event loop to manipulate the state of it or
others, only one event may be processed per epoll_wait. When multiple
events are queued up and a user removes an event input source from an
event loop from within a dispatch, if the removed source was one of the
queued up events
10 matches
Mail list logo