Andrew Ross writes:
> On Tue, Apr 28, 2009 at 09:40:14AM -0700, Alan Irwin wrote:
> > On 2009-04-28 10:45+0100 Andrew Ross wrote:
> >
> >> [...]I've been using HAVE_PTHREAD=ON for a long time with the xwin
> >> driver with no problems. It has certainly been enabled in the debian
> >> packages as well with no reported bugs. Based on this I am relatively
> >> sure that this bit is ok. The problem is that there is some extra code
> >> for handling user supplied windows which is currently only exercised by
> >> plframe. I suspect the error is there. Based on this I would like to
> >> propose that we disable HAVE_PTHREAD for plframe, but not more
> >> generally. We could do this by ensuring that -drvopt usepthread=0 is
> >> set in the plframe code.
> >>
> >> This would mean users don't have to choose between losing very useful
> >> functionality with xwin and potentially having a bug in the tk code. I
> >> think this is particularly important as the xwin driver is I imagine
> >> much more widely used that the tk code. Does this sound acceptable to
> >> everyone?
> >
> > Hi Andrew:
> >
> > You may recall that the lost text problem for -dev xcairo windows resizing
> > was spread by HAVE_PTHREAD=ON to the case where even the window focus was
> > being changed. I now assume that was just HAVE_PTHREAD=ON doing its job
> > since I just checked that Hazen's recent fix for the lost text -dev xcairo
> > issue also works fine for the HAVE_PTHREAD=ON case. Thus, your suggested
> > much more minor workaround of simply turning HAVE_PTHREAD OFF just for the
> > Tk case rather than in general is fine by me.
>
> I tried this but it produces a rather curious result. I added a call to
> plsetopt("drvopt","usepth=0") in plframe.c just before the call to
> plsdev("xwin"). Adding printfs into drivers/xwin.c shows that this really
> does result in usepthreads being set to 0. All the pthread specific code
> is wrapped in "if (usepthreads)" statements. Suprisingly the segmentation
> faults still occur even in this case. Only setting HAVE_PTHREADS=OFF seems
> to cure the problem. This is a rather surprising result. As far as I can
> see this only leaves two possibilities 1) Something in the headers
> included in the pthreads case is upsetting things 2) Some different link
> options are used if HAVE_PTHREADS=ON.
>
> Anyway, this narrows down the possibilities a lot.
I'm not sure what to say. If you work up something you want me to test, I'll
try to do so. But I'm too busy with a work situation right now, to
personally invest much time in studying the xwin.c code during this short
time leading up to the release. I did try (to understahnd the HAVE_PTHREAD
code) last weekend, but so far I simply haven't been able to "pick up the
vibe" so to speak.
I certainly agree that a threaded approach to event handling seems like a
productive way to improve the interactive responsiveness. But unless I'm
really missing something, I'm inclined to think the whole problem is a lot
easier in the bare xwin driver case, than in the widget with reparented X
window case (plframe). In the former, I think (could be wrong here), that
it's basically the event thread which takes all the events and does all the
processing. In the widget wrapper of the xwin case (plframe), there's no way
to prevent the main thread from receiving events, so the main thread and the
event thread have to be carefully synchronized. That just seems like more
work to me, than what I think I see in the HAVE_PTHREAD code. So, as I've
said, so far I haven't been able to convince myself that the approach
as-coded, is even really correct-in-principle, nevermind the possibility of
simple bugs. It seems to me, something considerably more robus is required
to have a functional threaded Tk frame widget.
In my own application, I'm being currently a little tempted to just ditch the
idea of multithreading the plframe itself. Instead, just dissociate all
computation into (a) sepearate thread(s), and leave the main thread, which
services all Tk processing, to handle plframe X events, just like it handles
all other widget X events. In other words, just forget multi-threading the X
part, and stick with single threading for the widget business, and achieve
better interactivity by moving all non-widget stuff to other threads. That
approach seems simply easier to code correctly.
But, I could be wrong. I need to study it a lot more before I can articulate
a firm point of view on these matters.
--
Geoff
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
