[reSIProcate] Maybe there have a bug with 1.3 RC1

[Karlsson]

I have encountered the join is not returned, it's blocked at
WaitForSingleObject(mThread,INFINITE); I'm sure I jsut called the join from
only one thread.
So I use the detach to instead join in my project.


Currently I use for my project, the thread() will set a bool if it
returning, and before detach the thread I'm poll this bool every 20ms.



On Tue, Apr 1, 2008 at 12:09 AM, Byron Campen <bcampen at estacado.net> wrote:

>  Just to be clear, you can only call join() from one place; multiple calls
> to join() from multiple threads (into the same thread) is undefined.
>
> Maybe the thing to do is have a bool set when pthread_join returns.
> waitForShutdown() could watch this bool instead (ie, returns once the thread
> is _actually_ done). (We'd have to write similar code for Windows, haven't
> looked at it yet)
>
> Best regards,
> Byron Campen
>
>
>  seems mShutdownCondition.wait(mShutdownMutex, ms); always returned false.
>
>
> (Why I do not using the join() ? Becaue in some case the join never
> return. so I MUST need the detach after I waiting
> the thread a while0.
>
>
> Now I use these case for my UA, it's working fine.
>
>
> #include <WinSock2.h>
> #include <Windows.h>
> #include <string>
> #include <iostream>
>
> using namespace std;
>
>
> #include <rutil/ThreadIf.hxx>
>
> using namespace resip;
>
>
> #ifdef _DEBUG
> #pragma comment(lib, "../lib/RutilD.lib")
> #else
> #pragma comment(lib, "../lib/Rutil.lib")
> #endif
>
> #pragma comment(lib, "ws2_32.lib")
>
>
> class MyThread : public ThreadIf
> {
>
> public:
>  MyThread() { mExit = false; };
>  ~MyThread() { mExit = false; };
>
>  void thread()
>  {
>   while(isShutdown() == false)
>   {
>    Sleep(5000);
>    cout << "Exit...." << endl;
>
>    mExit = true;
>   }
>  }
>
>  bool isExit() { return mExit; };
>
>
> private:
>  bool mExit;
>
> };
>
>
> int main()
> {
>  MyThread myThread;
>  myThread.run();
>
> Sleep(200);
>
>  myThread.shutdown();
>
>  DWORD counter = 0;
>  while (myThread.isExit() == false)
>  {
>   if (++counter >= 500)
>   {
>    break;
>   }
>
>   Sleep(20);
>  }
>
>
>  myThread.detach();
>
>
>  cout << "After detach." << endl;
>
>
>  return 0;
> }
>
>
>
>
> 2008/3/30, Karlsson <boost.regex at gmail.com>:
> >
> > Sorry for send again, the previous email is not clear:
> >
> >
> >  I think waitForShutdown(int ms) will be:
> > bool
> > ThreadIf::waitForShutdown(int ms) const
> > {
> >    Lock lock(mShutdownMutex);
> >    return mShutdownCondition.wait(mShutdownMutex, ms);
> > }
> >
> > I think the mShutdown just for isShutdown() only in thread(), we never
> > need check it in other areas.
> >
> > Then we can wirte these code for waiting a thread:
> >
> > int main()
> > {
> >  MyThread myThread;
> >  myThread.run();
> >
> >  Sleep(100);
> >
> >  myThread.shutdown();
> >
> >  DWORD counter = 0;
> >  while (myThread.waitForShutdown(20) == false)
> >  {
> >   if (++counter >= 500) // Waiting the thread 10 seconds.
> >   {
> >    break;
> >   }
> >  }
> >
> >
> >  myThread.detach();
> >  cout << "After detach." << endl;
> >
> >
> >  return 0;
> > }
> >
> > Or
> >
> > int main()
> > {
> >  MyThread myThread;
> >  myThread.run();
> >
> >  Sleep(100);
> >
> >  myThread.shutdown();
> >
> >  while (myThread.waitForShutdown(200) == false)
> >  {
> >  }
> >
> >
> >  myThread.detach();
> >  cout << "After detach." << endl;
> >
> >
> >  return 0;
> > }
> >
> >
> >
> >
> > 2008/3/30, Byron Campen <bcampen at estacado.net>:
> > >
> > >  Hmm. That thread isn't actually shut-down. ThreadIf::shutdown() just
> > > sets a sentinel value that will only take effect the next time the
> > > StackThread finishes cycling. The waitForShutdown() call used to function
> > > simply as a sleep() call; the fact that it took a while to return was the
> > > only thing allowing the cycle to complete before everything went out of
> > > scope. mShutdown is set, but mShutdown is just the sentinel value, and there
> > > is no guarantee whatsoever that it is being honored. I'll think about this
> > > more in the morning.
> > >
> > >
> > >
> > > Best regards,
> > > Byron Campen
> > >
> > >
> > >
> > >
> > >
> > >  I'm using Visual C++ 8.0(Visual Studio 2005 with SP1 and SP1 for
> > > Vista Update), My OS is Vista+SP1.
> > > complied My applications and reSIProcate with MT and MTd mode, others
> > > are using default settings.
> > >
> > > Thanks
> > >
> > >
> > >
> > > 2008/3/30, Alan Hawrylyshen <alan at polyphase.ca>:
> > > >
> > > >
> > > > On 29-Mar-08, at 20:05 , Karlsson wrote:
> > > >
> > > > > Hi Alan, I'm sure, I use SVN to got all 1.3.0 source code to a new
> > > > > directory: reSIProcate13. The older reSIProcate in another
> > > > > directory: resiprocate122.
> > > > > I have complied the 1.3.0 RC1 completely, and My application
> > > > linked
> > > > > these new header files and LIBs, I complied all reSIProcate module
> > > > > as MTd and MT .
> > > > > ...
> > > >
> > > > I apologize if you have indicated this previously, but what platform
> > > > are you using, along with specific compiler and runtime library
> > > > details? (Windows, Linux, BSD, Mac OS) and what compiler, variant of
> > > > OS, etc...
> > > >
> > > > Thanks,
> > > >
> > > > Alan
> > > >
> > > >
> > > _______________________________________________
> > > resiprocate-devel mailing list
> > > resiprocate-devel at resiprocate.org
> > > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> > >
> > >
> > >
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080401/341637a2/attachment.htm>