[gccsdk] pthreads WIMP filter code

John-Mark Bell jmb202 at ecs.soton.ac.uk
Wed Jan 3 16:28:57 PST 2007


On Wed, 3 Jan 2007, Alex Waugh wrote:

> John-Mark Bell <jmb202 at ecs.soton.ac.uk> wrote:
>
>> I've been looking at this recently with a view to making it actually work,
>> rather than relying on client applications to manually stop and start the
>> threading implementation either side of Wimp_Poll. I have what appears to
>> be working code now and I'd like some comments before this goes into SVN.
>
> It looks fine to me (but then the old code also looked fine, and that
> didn't work :) Am I right in thinking that the only significant
> difference is copying the filter name to RMA?

No ;)

The old code had the post filter mask inverted, and thus it would never 
have been called. Also, neither of {start|stop}_call_every preserved 
registers, thus corrupting things passed to and from the Wimp.

The copy filter name to RMA change is simply to avoid an Abort on Data 
Transfer within the FilterManager when issuing *Filters with the app 
paged out.

The other change in that patch is to explicitly check for the task having 
registered with the Wimp since the last time __pthread_start_ticker was 
called (otherwise the filters will never get installed). Obviously, this 
is predicated on __pthread_start_ticker being invoked after 
Wimp_Initialise has been called (and, crucially, before Wimp_Poll is 
called). That can be guaranteed by having the client initialise with the 
Wimp prior to any threads being created. I suspect a documentation update 
detailing this would also be sensible.

>> The patch may be found at http://moose.mine.nu/pthread-patches.zip (this
>> zip also contains a patch for __pthread_exit to prevent the function table
>> pointer it uses getting corrupted).
>>
>> I've tested this on various RO versions; namely 3.5, 3.6, 3.70, 3.71,
>> 4.02, 5.09 and 6preview. No adverse effects have been seen. Testing was
>> with both a Wimp application and a command line one running in a
>> taskwindow.
>
> Did you check that it was actually doing context switches? The old
> code appeared to work at first, until I realised that it was almost
> never doing any context switches when running in a taskwindow, and so
> didn't get a chance to fail.

Well, it had 3 threads, each printing to stdout. The output looked about 
right for the testcase. I can stick the code for that somewhere too, if 
you'd like.


John.




More information about the gcc mailing list