On Tue, Apr 28, 2009 at 08:57:16PM -0500, Geoffrey Furnish wrote:
> 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 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.
Turns out that I don't fully understand the rather complicated setup with the
tk drivers and in fact the xwin driver was being called before I had set the
driver options, though I can't see how.
> 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.
Further testing has shown that I can get rid of the segmentation fault by
removing the call to XInitThreads in the OpenXwin function in xwin.c.
According to the Xlib documentation:
"The XInitThreads() function initializes Xlib support for concurrent
threads. This function must be the first Xlib function a multi-threaded
program calls, and it must complete before any other Xlib call is made.
This function returns a nonzero status if initialization was successful;
otherwise, it returns zero. On systems that do not support threads, this
function always returns zero.
It is only necessary to call this function if multiple threads might use
Xlib concurrently. If all calls to Xlib functions are protected by some
other access mechanism (for example, a mutual exclusion lock in a toolkit
or through explicit client programming), Xlib thread initialization is
not required. It is recommended that single-threaded programs not call
this function."
The driver does protect all calls to Xlib with a mutex (that is what
most of the pthreads code in xwin.c is) and so I don't think this
call is necessary. This cause also ties in with the gdb backtrace
for the tk examples which shows that the segmentation fault was
occuring in pthreads routines called by Xlib routines, and not
in the plplot pthread code.
As I say, commenting out the call to XInitThreads results in the
tk examples running with no segmentation fault. The "normal"
xwin driver also appears to function correctly with no faults.
I am slightly unwilling to make this change so close to a release
as it could potentially impact on the stable xwin driver as well
as the tk support, particularly since I don't fully understand
what the pthread code is doing and how it interacts with the tk
code. As a result I can't explain exactly why there is a
problem for the tk support, but not for the vanilla xwin
driver. Perhaps we should stick with disabling pthread support
entirely for now, then make the change after the release to
allow proper testing? From Geoff's comments this may well need
a thorough review by someone who understands (or who has time
to work through) both the pthread and tk issues.
In particular, with the tk support there may be other Xlib calls
elsewhere which are not protected. It is also probable that
XInitThreads is not actually the first Xlib call in this case.
Andrew
------------------------------------------------------------------------------
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
