From: John Stone (johns_at_ks.uiuc.edu)
Date: Mon Jan 10 2005 - 18:44:30 CST

Bogdan,
  I guess what I find surprising about all of this is that these
fundamental libraries like libpthreads.so aren't nailed down with
a consistent interface. Assuming the library interface is consisent,
applications like VMD need not break when they re-implement them from
scratch. All VMD wants are the pthreads APIs, nothing that's remotely
Linux-specific really, so I'm surprised it would be vulnerable to changes
in the back-end implementation of the linux threads system. I suppose
that one potential cause for problems would be if they implemented some
of the old pthreads stuff with macros in header files rather than using
real entrypoints, that'd certainly break things when changing to a new
implementation. In any case, I don't have the means nor the time to
test against more than one or two linux distributions locally, so I'll
have to rely on feedback from others in going any further with this
proposed change.

  John Stone
  vmd_at_ks.uiuc.edu

On Mon, Jan 10, 2005 at 04:56:14PM +0100, Bogdan Costescu wrote:
> On Thu, 6 Jan 2005, John Stone wrote:
>
> > If not, then there'd be no reason to add that to the new startup
> > script, but if so, then I agree that may be a smart move, to prevent
> > this problem from affecting others.
>
> The threading problem comes from differences between the
> compile/link-time environment and the runtime environment. It's mostly
> a difference between your choice of Linux distribution for
> compiling/linking and the choice of Linux distribution by the user at
> runtime. Different distributions chose different ways and different
> times of dealing with the new threading model, that's why these
> problems appear; however, so far, the incidence of this problem with
> VMD is low enough that a general solution might not be worth doing.
> Providing a VMD binary distribution means making a choice about the
> compiling/linking behaviour; you are obviously not able to control the
> runtime environment, so I think that there are several ways of dealing
> with it:
> - just document what change is needed to the startup script for those
> few that encounter the problem
> - make the change to the startup script and hope that this covers all
> cases
> - create 2 different binary distributions that are compiled/linked in
> the 2 different threading enviroments
>
> > Honestly though, this is really a problem with the Linux threads
> > runtime and not VMD itself. I'd rather that the Linux distros fix
> > their threads library to avoid this kind of problem in the first
> > place.
>
> The threading "problem" comes from switching from the older pthreads
> to the new NPTL. The switching involves both kernel and glibc changes
> and therefore some distributions avoided them until recently when they
> started being enabled by default (unlike Red Hat Linux 9, which is
> quite old, but has NPTL support). NPTL is here to stay, so it's quite
> safe to say that future builds of VMD (hopefully on some up-to-date
> distribution) will actually be built in a NPTL environment and no
> longer in a pthreads one, therefore setting LD_ASSUME_KERNEL will not
> be needed anymore (and might actually be harmful).
>
> For reference, the LD_ASSUME_KERNEL values are explained at:
>
> http://people.redhat.com/drepper/assumekernel.html
>
> > No other OS has this type of problem, AFAIK.
>
> When was the last time an OS changed their threading implementation ? ;-)
>
> --
> Bogdan Costescu
>
> IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
> Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
> Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
> E-mail: Bogdan.Costescu_at_IWR.Uni-Heidelberg.De

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349              
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078