| Re: more IDL falls asleep [message #25186] |
Fri, 25 May 2001 09:08  |
deja_jlin
Messages: 12
Registered: February 2001
|
Junior Member |
|
|
hi Wayne,
thanks for the message! yes, it's a comfort to know i'm not alone :)
Wayne Landsman <landsman@mpb.gsfc.nasa.gov> wrote in message news:<3B0E0B86.CCB65580@mpb.gsfc.nasa.gov>...
>
> We've had problems with IDL falling asleep under a node-locked V5.4 license and
> a dual-processor machine running Solaris 2.7. We strongly suspected the
> license manager since it occurs with both V5.3 and V5.4 under the V5.4 license
> manager, but never with V5.3 under the V5.3 license manager. The problem also
> seems to be more likely to occur if the machine has many other processes
> running.
>
what license managers were the v5.3 and 5.4 machines running?
thanks!
best,
-Johnny
-------------------------------------------
Johnny Lin
CIRES, University of Colorado
Work Phone: (303) 735-1636
Web: http://cires.colorado.edu/~johnny/
-------------------------------------------
|
|
|
|
|
|
| Re: more IDL falls asleep [message #25296 is a reply to message #25186] |
Tue, 29 May 2001 13:39  |
deja_jlin
Messages: 12
Registered: February 2001
|
Junior Member |
|
|
hi all,
the folks at RSI responded re this problem, and it has to deal with the
license manager. here's the applicable parts of their reply (the technical
term for IDL sleeping and never waking up again is "deadlock"):
If it is indeed deadlock, then I believe you are encountering a weakness in
FLEXlm licensing that is generally only observable in very "large" IDL
processes. It is based on an implementation of malloc() in FLEXlm that is
not thread-safe. To keep a constant tab on licensing status in its network
FLEXlm sends out a periodic query to each of its clients. This query uses
the unsafe malloc() call. There is a very minute probability that this call
might be concurrent with an IDL use of system malloc(), and that is where
the deadlock occurs. Very large IDL processes that have many calls
allocating new memory are capable of defying the odds and experiencing this
deadly concurrency. We have actually never been able to (knowingly)
reproduce this in-house, but identified the clash in 'pstack' output from
our customers. You also would probably see the concurrent malloc() calls in
your own run of 'pstack' on the ID of a process that has "fallen asleep."
Our only solution is Research Systems' own licensing protocol, Genver
licensing. The downside to Genver licensing is that it must be renewed every
180 days, and you must have a separate license for each individual host that
is running your long IDL programs.
they're working on fixing this for the 5.5 release, but aren't sure if it will
be ready then, since fixing it is actually quite tricky.
hope this helps others experiencing this problem!
best,
-Johnny
-------------------------------------------
Johnny Lin
CIRES, University of Colorado
Work Phone: (303) 735-1636
Web: http://cires.colorado.edu/~johnny/
-------------------------------------------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
