On 07/19/10 10:37 PM, Peter Jeremy wrote:
On 2010-Jul-17 08:52:49 +0100, "Dr. David Kirkby"<david.kir...@onetel.net>  
wrote:
I don't know if you have every written multi-threaded code, but it is
non-trivial and very easy to make a mistake. Experience shows me that those
mistakes show up on on one platform only. It's hard enough to track the bug if
you wrote the code yourself, since the bugs are not always reproducible. It
would be 100x harder if someone else had written the code.

Multi-threaded bugs often manifest as race conditions - which are
notoriously hard to track down.

So IMHO, it would be unwise to *only* have an ability to set the number of
threads globally. What may be more useful, is an ability to set the number of
threads globally, but have the ability to override that for particular cases.

How about an extension to the standard environment variable parsing
so that SAGE_FOO_bar is equivalent to (and overrides) SAGE_FOO in
package 'bar' only?  This allows variables to be overridden for
specific packages without having to explicitly define lots of
specific environment variables.

Assuming $pkg contains the package name, you can assign the result
to 'FOO' with:
    eval FOO="\${SAGE_FOO_$pkg:-$SAGE_FOO}"


So if I understand you correctly,

SAGE_NUM_THREADS=10

would set 10 threads globally in Sage, but

SAGE_NUM_THREADS_ATLAS=1

would override the 10 to 1 (single threaded) for just ATLAS. Have I got you correct? If so, that sounds an excellent idea.



Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to