Unfortunately Android threads do not support cancel and testcancel, so this Test cannot build for android. Do we really need a cancellation point, since we don't need to cancel the thread. Tvrtko's original solution seemed workable, if a bit less polished. Tim > -----Original Message----- > From: Intel-gfx [mailto:intel-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf > Of Chris Wilson > Sent: Monday, July 14, 2014 2:28 PM > To: Tvrtko Ursulin > Cc: Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH] tests/gem_userptr_blits: Race between > object creation and multi-threaded mm ops > > On Mon, Jul 14, 2014 at 02:13:22PM +0100, Tvrtko Ursulin wrote: > > On 07/14/2014 02:07 PM, Chris Wilson wrote: > > >>>You don't have any cancellation points in the loop. (mmap may or > > >>>may not be, it is not required to be.) > > >>> > > >>>But rather than use a global, just pass a pointer to a local struct. > > >> > > >>It doesn't need both a cancellation point and a flag. Should I just > > >>add pthread_testcancel in the loop and not have any flag at all? > > > > > >testcancel also neatly avoids the handwavely lack of mb(). > > > > Barrier for what? But it doesn't matter, I'll re-spin with testcancel. > > It just makes an assumption that the compiler and processor don't skip the > read. Since it so simple to be pedagolically correct, it seems pointless to leave > it using volatile. > > > >>>Oh, and igt_assert. But kill the asserts in mm_stress_thread() first. > > >> > > >>Why remove completely? My thinking was to use assert vs igt_assert > > >>to distinguish between assumptions about system behaviour, and > > >>igt_assert for assertions about tested functionality. > > > > > >If the assert fires you make the igt test runner angry. Might as well > > >report a test failure rather than break down completely. > > > > I am not familiar with the test runner, but if it cannot handle a test > > failing in a way other than it expects it so it deserves to be angry. > > :) But OK, I'll change it. > > Actualy the SIGABRT will be delivered to the thread so you just get an ugly > assert and a PASS if you do not propagate the failure... > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
