On 03/20/2012 02:28 PM, Jonas Ådahl wrote:
> On Tue, Mar 20, 2012 at 2:22 PM, Andreas Ericsson wrote:
>> When a dispatch for sourceA wishes to remove sourceB and sourceB
>> has input that isn't yet processed, we would run into the dreaded
>> "undefined behaviour" previously.
>>
>> With this patch,
On Tue, Mar 20, 2012 at 2:22 PM, Andreas Ericsson wrote:
> When a dispatch for sourceA wishes to remove sourceB and sourceB
> has input that isn't yet processed, we would run into the dreaded
> "undefined behaviour" previously.
>
> With this patch, the destroyed source is marked as such by its
> r
When a dispatch for sourceA wishes to remove sourceB and sourceB
has input that isn't yet processed, we would run into the dreaded
"undefined behaviour" previously.
With this patch, the destroyed source is marked as such by its
removal function and ignored while processing input. We free() it
only
On 03/20/2012 01:19 PM, Ander Conselvan de Oliveira wrote:
> Hi,
>
> See comments below.
>
> On 03/20/2012 12:31 PM, Andreas Ericsson wrote:
>> When a dispatch for sourceA wishes to remove sourceB and sourceB
>> has input that isn't yet processed, we would run into the dreaded
>> "undefined behav
Hi,
See comments below.
On 03/20/2012 12:31 PM, Andreas Ericsson wrote:
When a dispatch for sourceA wishes to remove sourceB and sourceB
has input that isn't yet processed, we would run into the dreaded
"undefined behaviour" previously.
With this patch, the destroyed source is ignored while pr
When a dispatch for sourceA wishes to remove sourceB and sourceB
has input that isn't yet processed, we would run into the dreaded
"undefined behaviour" previously.
With this patch, the destroyed source is ignored while processing
input and is later free()'d in the post_dispatch_check() loop.
Sig
