osmeest
commented
3 years ago The simplest way to add support for native threads would be to extend Message::init() and look for native thread attributes when Thread::current() returned nullptr. However, inspecting native thread attributes is going to be OS dependent, just like Thread uses multiple implementations of ThreadImpl depending on the target platform.
A cleaner way would be to split ThreadImpl in 3 parts:
- a part that is responsible for sleeping and yielding of the current thread (it's basically a class with only static methods; it can equally well become a "Details" namespace); there is no reason for keeping those methods inside an object;
- a part that is responsible for reading and writing attributes from a native thread (name, scheduler settings); it should also support joining threads in the native way (ie. using pthread_join but not Event::wait()); let's call it NativeThreadImpl; -- start would not be supported at this level
- a part that is responsible for storing attributes before the thread is created, handling attributes that have to be set before starting (stack size), starting ; this would remain ThreadImpl but based on NativeThreadImpl.
For simplicity sake, NativeThreadImpl could provide stubbed methods for setStackSize and start, since they make no sense for already running threads. Instead of deriving from ThreadImpl, a Thread would contain a NativeThreadImpl (or a ThreadImpl when it is created by Thread constructor).
matejk
aleks-f
PatternFormatter provides %T and %I to print the thread name and thread id. Those patterns depend on attributes of Message which are set in the init() function, using Thread::current() and calling getName() and getTid() on the thread if any. Since Thread::current() works only for a thread that has been created using Poco::Thread, it does not work for threads that were created in another library (eg. std::thread).