diff README @ 15:e395e387bd3c

FIX: now catching precursor signs of lock-up bug correctly ENHANCEMENT: As a side effect, mlWSAlloc and mlExec are faster.
author samer
date Thu, 02 Feb 2012 12:57:15 +0000
parents 173e1c48e335
children e0a1f92fcbc9
line wrap: on
line diff
--- a/README	Thu Feb 02 03:01:20 2012 +0000
+++ b/README	Thu Feb 02 12:57:15 2012 +0000
@@ -280,6 +280,28 @@
 	Removed unused Matlab functions from matlab/general.
 	Version 1!
 
+2012-02
+	Some changes to mlExec and mlWSAlloc to get around a problem that
+	was bedevilling the triserver project, which was using a Matlab
+	engine in a separate thread, receiving requests on a message queue,
+	and calling this library with call_with_time_limit. Something to
+	do with this combination (threads, signals etc) was causing the
+	Prolog system to lock up hard on returning to Prolog system
+	after a failing call to engGetVariable (which was getting stuck and
+	timing out).
+
+	I still don't know what causes the lock-up, but I was able to detect
+	some signs that it was coming *before* calling engGetVariable by looking
+	at the Matlab engine output buffer.
+
+	Eventual work around is not to use engGetVariable to get uniquevar
+	variable names (mlWSAlloc) or lasterr (mlExec) at all, but simply
+	to scrape these out of the output buffer. This seems to be a few
+	milliseconds faster too.
+
+	other changes: removed ml_debug/1 - would rather have a flag to
+	enable printfs in the C++ source.
+
 -------------------------------------------------------------------------
 ACKNOWLEDGMENTS