什么可以改变我背后的浮点控制字?

我有一个32位Windows应用程序,主要用Delphi编写,它使用8087 FPU执行浮点数值模拟。 我最近添加了使用Python API通过python2x.dll链接外部Python代码的function。 这个最近的变化导致了一些非常奇怪的行为。

该应用程序具有批处理模式,可以并行执行多个模拟以利用多核架构。 一旦Python代码在这个过程中被执行,我就开始在不同的线程上看到8087控制字的变化。 我仔细检查了这一点,我发现即使在从未调用Python DLL的线程中,控制字也发生了变化。

我知道这听起来很奇怪,但正如我所发现的那样,这种行为有机制performance出来。 我已经了解了信号。 我首先假设Python DLL正在设置进程信号处理程序(通过调用signal() ),并且这些信号处理程序负责更改控制字。 例如,一个与Python代码无关的线程可能会导致SIGFPE而这又可能会修改控制字。

我宁愿得出结论, signal()不是机制。 我安排在启动时执行Python代码。 然后我把信号处理程序设置回SIG_DFL 。 然后我开始模拟。 但仍然发生控制字变化。

我的问题(终于)是否有人知道控制字可以以这种方式改变的另一种机制。 我正在寻找中断,APC等,我想!

更新

控制字正在被更改为Intel默认值0x037F 。 这不同于0x027F的MSVC / Windows默认值。 我假设有些东西叫做FPINIT

我还发现Py_InitializeEx允许调用者停止Python设置信号处理程序。 即使我使用这种方法进行初始化,控制字也会发生变化,所以我更加确信这不是机制。

Solutions Collecting From Web of "什么可以改变我背后的浮点控制字?"

例如,具有DLL_THREAD_ATTACH标志的DllMain调用,请参阅msdn

更新

我发现了一个类似的问题的链接 – DLL加载“毒药”FPU控制字的新线程 。 但是,是的,这是关于Dll加载创建的线程。

如果我没有记错,那是德尔福的问题。 这里和这里有一些关于这个问题的讨论。 我记得在Delphi中编写一些VST插件时遇到了这个问题。

我曾经见过这种情况,默认打印机的打印机驱动程序改变了我的控制字。 当我更改默认打印机时,问题就消失了。 为了避免这个问题,我把这个控制字设置为默认值:

_control87(_CW_DEFAULT, _CW_DEFAULT);

我也看到在安装了诺顿安全软件2011的客户的所有机器上都出现同样的问题,但问题却随着打印机驱动程序的修复而消失,所以我不确定诺顿是否真的是这个原因。