From: Kenneth Porter on
[posted and mailed]

tim.kosse(a)gmx.de (Tim Kosse) wrote in news:elgl66$59s$1(a)sea.gmane.org:
> I encountered the same problem, though in a GUI application. From a
> function called Wait, I expected true waiting semantics, while
> wxThread::Wait can do other stuff like processing the message loop.
>
> I've written a simple class which simulates joinable threads using
> detached threads and wxCondition. See
> http://filezilla-project.org/codesquid/threadex.tar.bz2

You don't acquire the mutex for the condition variable until you Wait() for
the thread. That means you can miss signals if the thread exits before you
Wait(). You need to acquire the mutex before the thread is started. This
insures that the signal won't be sent until the launching thread is ready
to receive it.
From: "Iulian-Nicu Serbanoiu" on
>From what you are telling it seems that you are using it as a static library
under windows ( correct me if I'm wrong ).

If you are using it this way try using wxWidgets library as a DLL ( not
static ) ( DLL file(s) must be in PATH or in the working directory of the
application executable file ).

This way you *won't* need to wxInitialize/wxUninitialize when the dll( or
..so unde linux ) is loaded/unloaded as the wxwidgets instance is initialized
by the executable.

My guess is that one of the global variables are initialized TWICE because
you are using 2 instances of the wxWidgets library ( one static instance
exists in the EXE and another one in the DLL ). It may work on linux because
you are probably using a dynamic version of the wxwidgets library ---> only
one instance of the wxwidgets library ( the dll file and the exe file use
the same shared objects (.so) ).

Please provide more details about the way you are using wxWidgets (
static/dynamic ) on both linux/windows.

HTH,

Iulian

On 12/5/06, Marco Gubernati <marco.gubernati(a)erxa.it> wrote:
>
> Hi,
>
> I've got a dll that uses some features of wxWidgets. For example
> threads. Inside the dll no need to use any GUI functions, so I simply
> use wxInitialize/Uninitialize, in order to be able of starting threads.
>
>
From: "Marco Gubernati" on
Yuo're right: I used wxWidgets statically under windows, and dinamically under Linux. BUT, I don't thing the problem was related to that thing. You say: "you are using 2 instances of the wxWidgets library ( one static instance exists in the EXE and another one in the DLL )". My EXE was an MFC one, not directly depending on wxWidgets!

I solved the problem by developing a simple wrapper class around wxThreads (detached) that provides the functionalities of joinable ones using wxMutex and wxCondition.

At the moment I don't have much time to go back on that project, and giving you more details... but if you have any questions/suggestions, try to ask

regards.

M. G.
----- Original Message -----
From: Iulian-Nicu Serbanoiu
To: wx-users(a)lists.wxwidgets.org
Sent: Tuesday, January 16, 2007 8:49 AM
Subject: Re: Problems with wxThread::Wait in a dll under windows


>From what you are telling it seems that you are using it as a static library under windows ( correct me if I'm wrong ).

If you are using it this way try using wxWidgets library as a DLL ( not static ) ( DLL file(s) must be in PATH or in the working directory of the application executable file ).

This way you *won't* need to wxInitialize/wxUninitialize when the dll( or .so unde linux ) is loaded/unloaded as the wxwidgets instance is initialized by the executable.

My guess is that one of the global variables are initialized TWICE because you are using 2 instances of the wxWidgets library ( one static instance exists in the EXE and another one in the DLL ). It may work on linux because you are probably using a dynamic version of the wxwidgets library ---> only one instance of the wxwidgets library ( the dll file and the exe file use the same shared objects (.so) ).

Please provide more details about the way you are using wxWidgets ( static/dynamic ) on both linux/windows.

HTH,

Iulian


On 12/5/06, Marco Gubernati <marco.gubernati(a)erxa.it> wrote:
Hi,

I've got a dll that uses some features of wxWidgets. For example
threads. Inside the dll no need to use any GUI functions, so I simply
use wxInitialize/Uninitialize, in order to be able of starting threads.



From: Kenneth Porter on
[posted and mailed]

Kenneth Porter <shiva.blacklist(a)sewingwitch.com> wrote in
news:Xns98B99B612F3FCshivasewingwitchcom(a)216.196.97.142:

> tim.kosse(a)gmx.de (Tim Kosse) wrote in news:elgl66$59s$1(a)sea.gmane.org:
>> I encountered the same problem, though in a GUI application. From a
>> function called Wait, I expected true waiting semantics, while
>> wxThread::Wait can do other stuff like processing the message loop.
>>
>> I've written a simple class which simulates joinable threads using
>> detached threads and wxCondition. See
>> http://filezilla-project.org/codesquid/threadex.tar.bz2
>
> You don't acquire the mutex for the condition variable until you
> Wait() for the thread. That means you can miss signals if the thread
> exits before you Wait(). You need to acquire the mutex before the
> thread is started. This insures that the signal won't be sent until
> the launching thread is ready to receive it.

tim.kosse(a)gmx.de (Tim Kosse) wrote:

> I don't see any problem with my code. If the thread finishes before
> wxThreadEx::Wait() gets called, m_finished gets set to true.
> If wxThreadEx::Wait() gets called then, it doesn't wait on the condition.

Ah, I stand corrected. You use the m_finished member as a saved signal and
it's protected by the condition's mutex.