[gccsdk] pthreads WIMP filter code

Alex Waugh alex at alexwaugh.com
Thu Jan 4 12:07:42 PST 2007

John-Mark Bell <jmb202 at ecs.soton.ac.uk> wrote:

> 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.

Ah, the mask is probably the key bit that was missed before. Is the
description of the mask in the PRMs incorrect then, or just highly
> 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.

It could be switching context because of implicit calls to
pthread_yield on return from thread unsafe functions. Although if
it also works in a wimp application then it is less likely to be
affected by not switching. If you haven't done already, I'd certainly
recommend running the test programs unixlib/source/test/pthread.


Alex Waugh                                           alex at alexwaugh.com

PHP, Roots, Subversion, WebJames and more from http://www.alexwaugh.com/

More information about the gcc mailing list