Re: [SOSlib-discuss] Is SOSLib Thread-Safe?[Scanned]

[Eric F. <efe...@ph...>]

Hi,

I wonder if this has to do with the problem I reported yesterday with
encapsulation of integratorInstance in C++ objects. If an
integratorInstance (and settings) is created in the constructor, then
the integrateOneStep() segfaults if it is done in a member function. I
have to create the integrator, integrate and then free the integrator
within the member function to make it work, leading to code redundancy.

Eric

> -----Original Message-----
> From: sbm...@li... 
> [mailto:sbm...@li...] On 
> Behalf Of Rainer Machne
> Sent: 19 September 2008 09:14
> To: Eva Sciacca
> Cc: sbm...@li...
> Subject: Re: [SOSlib-discuss] Is SOSLib Thread-Safe?[Scanned]
> 
> Hi Eva,
> 
> We have ourself not used Java bindings. Can you give some 
> more details which structures/functions you are using, that 
> might cause the problem?
> Which version are you using (there is only 1.6 and CVS :) - 
> if CVS which date approx.)?
> 
> In principle SOSlib is intended to be thread-safe! odeModel_t 
> and integratorInstance_t (and all other) structures can be 
> created, used and free'd independently, and should not cause 
> any memory leaks or corruptions. From one SBML model many 
> independent odeModel structures, and from each odeModel many 
> independent integratorInstance structures can be created (and 
> integrated in parallel). We are not aware of any current 
> problems with that.
> 
> Here some suggestions of past problems:
> 
> I am not aware of of any memory problems in the 1.6 release either.
> However, an old CVS version used TCC-based compilation and 
> wasn't thread-safe because unfortunately TCC (as a library) 
> is not thread-safe - we removed TCC compilation for that 
> reason, and currently use gcc command-line calls or - very 
> new - our own internal compiler.
> 
> Also, some recent libSBML versions had memory problems with 
> ASTNode structure, not freeing all parts of the abstract 
> syntax tree correctly. It could be related to this. I am 
> currently using libSBML CVS and haven't tested their latest 
> official release, yet. Which libSBML version are you using?
> 
> 
> Btw, we are currently working on a new release, which should 
> come in the next few weeks. The code has been significantly 
> enhanced since 1.6 and we'd be happy to support with 
> transition to the new code. For us it would be great to get 
> feedback already for the current CVS version before making 
> the official release :) However, I will commit a major change 
> today (increasing speed for large models significantly), so 
> you might want to wait a bit.
> 
> Thanks,
> Rainer