[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-glpk] [Fwd: GLPK 4.38 Re-entrancy 64-bit windows]
From: |
Andrew Makhorin |
Subject: |
[Help-glpk] [Fwd: GLPK 4.38 Re-entrancy 64-bit windows] |
Date: |
Fri, 11 May 2012 02:28:47 +0400 |
-------- Forwarded Message --------
From: Nicholas Nash <address@hidden>
To: address@hidden
Subject: GLPK 4.38 Re-entrancy 64-bit windows
Date: Thu, 10 May 2012 20:12:13 +0100
Hi,
I have some legacy code that is using GLPK 4.38, despite much searching
online I can’t get definitive answers to some questions.
Is GLPK 4.38 re-entrant? The code I have is multi-threaded and running
in a Windows 64-bit environment, calling GLPK from C#.
A single GLPK problem is only ever accessed in a single thread; although
many threads create their own GLPK problems and solve them.
I can see code in glplib02.c that allocates thread local storage, so am
I correct that the usage I have described above is safe?
Despite using GLPK as above, I still occasionally see this error
reported:
xfree: memory allocation error
Error detected in file ..\src\glplib07.c at line 181
Since I’m not out of memory, guessing at the code makes it looks like
there was an unmatched free/delete (or there was a threading issue
related to a counter).
Is this a known bug in GLPK 4.38, or is the bug more likely to be mine?
Would moving to a later version help?
Thanks,
Nick
- [Help-glpk] [Fwd: GLPK 4.38 Re-entrancy 64-bit windows],
Andrew Makhorin <=