Re: Tcl [exit] hanging?

Troy wrote:

On Apr 9, 5:02 pm, Jeff Godfrey <jeff_godf...@xxxxxxxxx> wrote:
rocket777 wrote:
Just noticed, that twapii::end_process also allows for an optional
exit code too!!

http://twapi.magicsplat.com/process.html#end_process

Great.  I'll look into it.  While I'd certainly like to get to the
bottom of the real issue, maybe that'll at least buy me some time.

Thanks.

Jeff

We've also seen this problem at work. We were using TclBlend, and so
we worked around it similarly, by exiting using the java system exit
command instead of tcl exit. Seeing this today prompted me to ask my
coworker who investigated this (we had been plagued by this for
years), and he filed a bug (http://sourceforge.net/tracker/?
func=detail&aid=2750491&group_id=10894&atid=110894) that contains more
information on what he found about it and how to possibly work around
it.

I suspect the commit below may have fixed it in 8.6. There was some
questionable code in tclWin32Dll.c. I recall we discussed it at the
Tcler's Chat at some length. Joe English in particular was quite against
the code pattern, because of the problems it could introduce, and the MSDN
documentation warned against what Tcl was doing.

2008-08-01 Jeff Hobbs <jeffh@xxxxxxxxxxxxxxx>

* doc/Exit.3: Do not call Tcl_Finalize implicitly
* generic/tclEvent.c: on DLL_PROCESS_DETACH as it may lead
* win/tclWin32Dll.c (DllMain): to issues and the user should be
explicitly calling Tcl_Finalize before unloading regardless. Clarify
the docs to note the explicit need in embedded use.

So it's quite possible the code before lead to some races, or parts of the
Windows DLL code causing a deadlock.

This is what the MSDN documentation has to say about what Tcl was doing:
"Calling functions that require DLLs other than Kernel32.dll may result in
problems that are difficult to diagnose. For example, calling User, Shell,
and COM functions can cause access violation errors, because some functions
load other system components. Conversely, calling functions such as these
during termination can cause access violation errors because the
corresponding component may already have been unloaded or uninitialized.

Because DLL notifications are serialized, entry-point functions should not
attempt to communicate with other threads or processes. *Deadlocks* may
occur as a result."

See also: http://msdn.microsoft.com/en-us/library/ms682583.aspx

The emphasis on "Deadlocks" was added by me.

As far as I know Tcl uses multiple threads in Windows, and so does Tk for
Windows. The code that Tcl_Finalize uses manipulates and cleans up a lot
of global thread state, and that was unsafe to do from a DLL_PROCESS_DETACH
path. It was also using DLLs other than Kernel32.dll.

In fact the developer that added it seems to have known some of that, based
on the comment in see in 8.5.

" * Side effects:
* Establishes 32-to-16 bit thunk and initializes sockets library. This
* might call some sycronization functions, but MSDN documentation
* states: "Waiting on synchronization objects in DllMain can cause a
* deadlock."

In other words, the code was flawed, and the person that added it really
shouldn't have.

-George
.

Relevant Pages

  • Re: Bizarre and annoying compiler error message.
    ... if I exit VS and go back in I do not have to delete the obj directory. ... All of my DLL references for DLL are set to CopyLocal=true. ...
    (microsoft.public.dotnet.general)
  • Re: QueueUserWorkItem with functions in a DLL, how to unload safely?
    ... special event handle that only gets signalled when you want the thread to exit. ... unload code will know when it's safe. ... You'll likely need some way of signalling them to stop normal ... The DLL is part of a Plugin-Concept ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Determine if the main app is a console or GUI?
    ... Don't issue error messages at all, ever, under any conditions. ... And in a DLL, NEVER, EVER, ... FOR ANY REASON IMAGINABLE, EVER, UNDER ANY CIRCUMSTANCES, call Exit(). ... a console app as well as from a GUI app. ...
    (microsoft.public.vc.mfc)
  • Re: Exiting an Application from within a Dll
    ... Internal consistency error doesn't mean sqrt. ... They provide a DLL to use it from application. ... I have yet to find a situation in which exit() made sense. ... The correct response is to make sure that data corruption cannot be ...
    (microsoft.public.vc.mfc)
  • Re: [PATCH] fix-flush_workqueue-vs-cpu_dead-race-update
    ... for the same worker thread to exit. ... The test fails in the window described above. ... otherwise we have a deadlock if work->funcsleeps and re-queues itself. ... This way workqueue will have almost zero interaction ...
    (Linux-Kernel)