plplot-devel

[Plplot-devel] --with-pthreads: Use pthreads with the xwin driver!

[Joao C. <jc...@fe...>]

Hi,

The xwin driver has been plagued for ages with a severe problem: whenever=
 the=20
user program goes to lengthly calculations, without doing any calls to=20
PLplot, the plot window couldn't be refreshed if obscured by other window=
s.=20
Nor resized.

You can quickly watch this behavior if you insert a getchar() statement j=
ust=20
before plend() in x01c.c. The getchar() call simulates the user program d=
oing=20
other jobs and not calling any plplot API. If you now obscure the plot wi=
ndow=20
you will see that it is not redrawn (of course).

This behaviour is most inconvenient for interactive languages like Octave=
 or=20
python, where the same behaviour is observed while the user is typing=20
commands at the prompt.

The obvious solution would be to write a xwin server or daemon, like the =
tk=20
driver plserver, but that means a lot of work. Instead, I have implemente=
d,=20
and cvs commit, a threaded xwin driver. It updates and resizes the plot=20
window, if needed.

This feature is disabled by default at configure time.

For most compiled programs, it can be safely turned on, even if the host=20
program is not threads aware.
For already build programs that somehow use PLplot, usually loading it as=
 an=20
extension, as Octave or python or tk does, things are a bit complicated, =
as=20
those programs must themself be linked with the pthread library, even if =
not=20
thread aware!

For example, in my system Octave is build by default without being linked=
 with=20
pthreads, because Octave is not threads aware. To use the new threads ena=
bled=20
xwin driver, I have to *relink* (only) octave with -lpthread, and after t=
hat=20
all goes well.

Python, by contrary, is already linked with the pthreads library, so noth=
ing=20
special needs to be done -- the threads enabled xwin driver works without=
 a=20
problem with python.

This is the reason why --with-pthreads=3Dno by default, and should not be=
 turned=20
on.
But users must know that this feature is available and why it is turned o=
ff,=20
so they can turn it on if that is the appropriate action for them.

Enjoy,
Joao

Re: [Plplot-devel] --with-pthreads: Use pthreads with the xwin driver!

[Alan W. I. <ir...@be...>]

On Wed, 5 Mar 2003, Joao Cardoso wrote:

> For most compiled programs, it can be safely turned on, even if the host
> program is not threads aware.
> For already build programs that somehow use PLplot, usually loading it as an
> extension, as Octave or python or tk does, things are a bit complicated, as
> those programs must themself be linked with the pthread library, even if not
> thread aware!

I believe the best solution here is simply to link xwin with -lpthread
consistent with the hierarchichal linking paradigm we are using. That way,
all pthread symbols in the xwin driver should be resolved, and you shouldn't
have to do any special linking of octave, wish, tclsh, etc.  This is for the
dynamic drivers case.  In the static drivers case it is a little bit more
complicated; the xwin driver becomes part of libplplot, and therefore,
libplplot has to be linked with -lpthread.

The short story: make Makefile.am changes for the xwin driver following what
happens for the gd driver special libraries (libgd, libpng, etc) as a model
both for the dynamic and static drivers cases.

If you or Rafael don't have time to fiddle with this, I will have a look
this weekend.  If it works out, then perhaps you will not have to turn off
pthreading by default.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] --with-pthreads: Use pthreads with the xwin driver!

[<jc...@fe...>]

On Wednesday 05 March 2003 01:16, Alan W. Irwin wrote:
| On Wed, 5 Mar 2003, Joao Cardoso wrote:
| > For most compiled programs, it can be safely turned on, even if the
| > host program is not threads aware.
| > For already build programs that somehow use PLplot, usually loading
| > it as an extension, as Octave or python or tk does, things are a
| > bit complicated, as those programs must themself be linked with the
| > pthread library, even if not thread aware!
|
| I believe the best solution here is simply to link xwin with
| -lpthread consistent with the hierarchichal linking paradigm we are
| using. That way, all pthread symbols in the xwin driver should be
| resolved, and you shouldn't have to do any special linking of octave,
| wish, tclsh, etc.  This is for the dynamic drivers case.  In the
| static drivers case it is a little bit more complicated; the xwin
| driver becomes part of libplplot, and therefore, libplplot has to be
| linked with -lpthread.
|
| The short story: make Makefile.am changes for the xwin driver
| following what happens for the gd driver special libraries (libgd,
| libpng, etc) as a model both for the dynamic and static drivers
| cases.
|
| If you or Rafael don't have time to fiddle with this, I will have a
| look this weekend.  If it works out, then perhaps you will not have
| to turn off pthreading by default.

I don't things are as simple as that.

Adding the pthread library to a program not only adds more 
functionalities to it but also changes the way how it is executed and 
how certain global variables (errno, e.g.) are acessed.

When a program not linked with pthreads loads the xwin driver, and 
implicitly the pthreads library, as you suggest, it is too late for it 
to adapt to the new execution model.

But you can try. I'm no threads expert.
Don't forget to try with already compiled programs that load plplot, 
octave or python, e.g., and are/are not linked with pthreads by 
default.
Please report your experiences before commiting things.

Joao

|
| Alan
| __________________________
| Alan W. Irwin
| email: ir...@be...
| phone: 250-727-2902
|
| Astronomical research affiliation with Department of Physics and
| Astronomy, University of Victoria (astrowww.phys.uvic.ca).
|
| Programming affiliations with the Canadian Centre for Climate
| Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot
| scientific plotting software package (plplot.org).
|
| __________________________
|
| Linux-powered Science
| __________________________

Re: [Plplot-devel] --with-pthreads: Use pthreads with the xwin driver!

[<jc...@fe...>]

On Wednesday 05 March 2003 00:06, Joao Cardoso wrote:
| Hi,
|
| The xwin driver has been plagued for ages with a severe problem:
| whenever the user program goes to lengthly calculations, without
| doing any calls to PLplot, the plot window couldn't be refreshed if
| obscured by other windows. Nor resized.
|
| You can quickly watch this behavior if you insert a getchar()
| statement just before plend() in x01c.c. The getchar() call simulates
| the user program doing other jobs and not calling any plplot API. If
| you now obscure the plot window you will see that it is not redrawn
| (of course).
|
| This behaviour is most inconvenient for interactive languages like
| Octave or python, where the same behaviour is observed while the user
| is typing commands at the prompt.
|
| The obvious solution would be to write a xwin server or daemon, like
| the tk driver plserver, but that means a lot of work. Instead, I have
| implemented, and cvs commit, a threaded xwin driver. It updates and
| resizes the plot window, if needed.
|
| This feature is disabled by default at configure time.
|
| For most compiled programs, it can be safely turned on, even if the
| host program is not threads aware.
| For already build programs that somehow use PLplot, usually loading
| it as an extension, as Octave or python or tk does, things are a bit
| complicated, as those programs must themself be linked with the
| pthread library, even if not thread aware!
|
| For example, in my system Octave is build by default without being
| linked with pthreads, because Octave is not threads aware. To use the
| new threads enabled xwin driver, I have to *relink* (only) octave
| with -lpthread, and after that all goes well.
|
| Python, by contrary, is already linked with the pthreads library, so
| nothing special needs to be done -- the threads enabled xwin driver
| works without a problem with python.
|
| This is the reason why --with-pthreads=no by default, and should not
| be turned on.

Perhaps in a future development it will be enabled  by default at 
configure time but disabled by default at run-time. To enable it at 
run-time one could use a driver-specific option, like -drvopt pthreads.
This would be the best of both words.

Joao