瞭解Tcl_DeleteInterp（）API

我有Tcl_DeleteInterp（）API（在solaris上）的一些問題。我在我的應用程序中使用了這個Tcl_DeleteInterp（）來刪除解釋器。我發現的奇怪的事情是使用此API的過程掛起大約20分鐘。我用truss命令附加了這個過程，發現這個過程繼續執行下面的函數將近20分鐘。瞭解Tcl_DeleteInterp（）API

15.6541 0.0002 -> libtcl8.4:Tcl_DeleteInterp(0x41748, 0x0, 0x0, 0x0) 
15.6580 0.0039 -> libc:free(0x288f8, 0x0, 0x0, 0x0) 
15.6583 0.0003 -> libc:mutex_unlock(0xff0424e8, 0x0, 0x0, 0x0) 
15.6584 0.0001 <- libc:free() = 0 
15.6588 0.0004 -> libc:free(0x474b0, 0x0, 0x0, 0x0)* 
... 
...

有人可以幫我解釋爲什麼函數Tcl_DeleteInterp調用這些函數嗎？我也檢查了爲Tcl_DeleteInterp（）完成的實現，但沒有找到任何線索。

感謝

來源

2014-01-23 sakthivp

Tcl_DeleteInterp刪除Tcl解釋上下文。作爲它的一部分，它破壞了該解釋器中的命名空間，命令和變量（Tcl沒有全局變量，對於特定的解釋器上下文，所有東西都是局部的）。反過來，這種刪除恰好將內存釋放回主內存管理器和可能的操作系統;這就是爲什麼free()被調用;它可能會在某些配置中間接調用，但會被調用。（如果在解釋器上下文中有一個主動執行 - 也就是對Tcl_Eval()或其相關函數之一的調用 - 某些刪除將被推遲直到執行完成。）還有一些回調（呃，還有很多他們）可以設置檢測各種刪除;那些可以（也很可能會）自由的事情。

我不知道是什麼導致掛起，但在猜測看起來好像你有另一個線程是錘擊系統內存分配器，保持內存分配器的全局鎖定過於緊密。如果是這樣的話，那很不好。在這種情況下，最好是嘗試升級到支持線程的Tcl 8.5或8.6版本（我建議，無論如何; 8.4現在不支持非商業支持），因爲它使用自定義內存分配器， t幾乎從全局內存池中分配（和釋放）。我不要知道那會解決的事情;我懷疑這個bug並不在Tcl的實現中，而是在其他代碼中。（它肯定不是在Tcl腳本中，除非你有一些奇怪的擴展代碼導致了問題。）

來源

2014-01-23 08:47:44

感謝您的回答Donal – sakthivp

瞭解Tcl_DeleteInterp（）API

回答

相關問題