Re: BOOST_THREAD_HAS_EINTR_BUG...

From: David Bien (davidbien_at_[hidden])
Date: 2024-04-26 19:23:06

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 <boost-bounces_at_[hidden]> on behalf of David Bien via Boost <boost_at_[hidden]>
Sent: Friday, April 26, 2024 11:30 AM
To: Peter Dimov <pdimov_at_[hidden]>; boost_at_[hidden] <boost_at_[hidden]>
Cc: David Bien <davidbien_at_[hidden]>
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 <pdimov_at_[hidden]>
Sent: Friday, April 26, 2024 11:25 AM
To: 'David Bien' <davidbien_at_[hidden]>; boost_at_[hidden] <boost_at_[hidden]>
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 <pdimov_at_[hidden]>
> Sent: Friday, April 26, 2024 11:15 AM
> To: 'David Bien' <davidbien_at_[hidden]>; boost_at_[hidden]
> <boost_at_[hidden]>
> 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=0<http://lists.boost.org/mailman/listinfo.cgi/boost>