Re: [boost] BOOST_THREAD_HAS_EINTR_BUG...

26 Apr 2024

      Ok, so I asked copilot - LMAO!!!

It suggested, and I didn't think it made sense but I tried it, to change the class member declaration order to destruct the std::thread first.

  std::weak_ptr< CGlobals > m_wpGlobals;
  std::unordered_map< boost::uuids::uuid, CSession, std::hash< boost::uuids::uuid > > m_sessions;
  boost::shared_mutex m_mutex;
  std::chrono::minutes m_nMinutesCleanupSession;
  bool m_fRunning;
  boost::mutex m_cvMutex;
  boost::condition_variable m_cv;
  std::thread m_thread;

I had it somewhere in the middle - but importantly above the m_cv and m_cvMutex.

I ran it thirty times or so and didn't get a race or an EBUSY. Granted this is no guarantee - but it always failed before within a few runs.

Oh, and I also changed this - but things still failed after this change.
~CShareMgr()
{
  {
    boost::lock_guard< boost::mutex > lock( m_cvMutex );
    m_fRunning = false;
    m_cv.notify_one(); // moved this up from below the block.
  }
  if ( m_thread.joinable() )
  {
    m_thread.join();
  }
}

Does the change to destructing the std::thread() first make any sense to anyone at all? Cuz it doesn't make sense to me - the presumption is that the thread wasn't in a joinable state when joinable() was called?

A bit confused,
bien

________________________________
From: Boost  on behalf of David Bien via Boost 
Sent: Friday, April 26, 2024 11:30 AM
To: Peter Dimov ; boost@lists.boost.org 
Cc: David Bien 
Subject: Re: [boost] BOOST_THREAD_HAS_EINTR_BUG...

"Incidentally, underscore followed by a capital letter is reserved to the
implementation and you're not supposed to use such identifiers."

Yeah, people have been telling me that for 35 years of writing C++ - the fact is that the compiler mangles every single name - as you well know... I literally have never encountered a single problem due to my coding style.

Yeah, the pattern looks correct to me as well - I mean if the m_cv and m_cvMutex are passing then the thread should exit, no?

It seems foolproof - the code that is - no reason it shouldn't exit the cleanup thread. I'd love for someone to poke holes in this theory.

bien
________________________________
From: Peter Dimov 
Sent: Friday, April 26, 2024 11:25 AM
To: 'David Bien' ; boost@lists.boost.org 
Subject: RE: [boost] BOOST_THREAD_HAS_EINTR_BUG...

David Bien wrote:
...
Sure, but then there must be a bug in my code... do you see one? It's pretty
simple - and once again has worked for many weeks of testing under other
platforms.
No, I don't see a bug in the code you posted. (Assuming that m_thread
is joinable and executes _CleanupThread.)

Incidentally, underscore followed by a capital letter is reserved to the
implementation and you're not supposed to use such identifiers.
...
________________________________
From: Peter Dimov 
Sent: Friday, April 26, 2024 11:15 AM
To: 'David Bien' ; boost@lists.boost.org

Subject: RE: [boost] BOOST_THREAD_HAS_EINTR_BUG...
David Bien wrote:
...
When it aborts the return is EBUSY.
EBUSY means that you're destroying a locked mutex, so the abort is legitimate.
_______________________________________________
Unsubscribe & other changes: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.boost.org%2Fmailman%2Flistinfo.cgi%2Fboost&data=05%7C02%7C%7Cebf66098729e4302d7cc08dc661f0555%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638497530615589376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CI1k7on8sa8nfV%2Be8KRpGAzRXmeNiW%2FVrQL7ZCGB0%2Fc%3D&reserved=0http://lists.boost.org/mailman/listinfo.cgi/boost