www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - osthread internals: Let's cut the Thread class code in half?

reply Denis Feklushkin <feklushkin.denis gmail.com> writes:
Hi!

Well, maybe anyone remember that from time to time I push PRs 
aimed at supporting more operating systems and bare metal.

Once again, just like many years ago, I'm looking at the 
core.thread.osthread code. Now it's because of updating from the 
upstream of my "dfruntime" fork 
(https://github.com/denizzzka/dfruntime/). And this is still very 
difficult due to the OS-dependent structure of our code.

What I mean is Thread class code (and few other places): it 
contains many of version() branches like:

```d
~this() nothrow  nogc
{
     if (super.destructBeforeDtor())
         return;

     version (Windows)
     {
         m_addr = m_addr.init;
         CloseHandle( m_hndl );
         m_hndl = m_hndl.init;
     }
     else version (Posix)
     {
         if (m_addr != m_addr.init)
             pthread_detach( m_addr );
         m_addr = m_addr.init;
     }
     version (Darwin)
     {
         m_tmach = m_tmach.init;
     }
}
```

Let's assume that we add a couple more OSes here? This discredits 
our beautiful version() branching - using them this way means not 
making it easier, but confusing the code.

Idea is simple: let's make two Thread classes, for Windows and 
for Posix.

But previously (a long time ago, more than 5 years ago, I think) 
I already proposed similar cuts. (Moreover, I already have my own 
version of runtime, cut as I need it - see above). The main 
obstacle was that druntime code cannot be in a situation where we 
have two identical classes in our source tree, but compiled 
depending on the choised OS using `version()`), with the same 
method names. This is because classes need to be documented, but 
the documentation will also have to be duplicated and our doc 
parser cannot handle such a situation.

Has anything changed since then? Have community come up with any 
tricks to get around this problem?

Currently I think we are very close to supporting arbitrary OSes 
and bare metal targets. In fact, the problem voiced here is the 
only serious obstacle.
(And, presumably, the decision will also bring us closer to 
support wasm.)
As for me, it would be cool to close this gestalt.
Mar 22
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 22 March 2026 at 16:48:42 UTC, Denis Feklushkin wrote:

 But previously (a long time ago, more than 5 years ago, I 
 think) I already proposed similar cuts. (Moreover, I already 
 have my own version of runtime, cut as I need it - see above). 
 The main obstacle was that druntime code cannot be in a 
 situation where we have two identical classes in our source 
 tree, but compiled depending on the choised OS using 
 `version()`), with the same method names. This is because 
 classes need to be documented, but the documentation will also 
 have to be duplicated and our doc parser cannot handle such a 
 situation.

 Has anything changed since then? Have community come up with 
 any tricks to get around this problem?


In Phobos, we work around problems like this by creating separate 
`version (StdDdoc)` blocks, which are only used to generate 
documentation and never compiled. It should be possible to do 
something similar for druntime. (`version (CoreDdoc)`, maybe?)
Mar 22
parent reply Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Sunday, 22 March 2026 at 19:32:58 UTC, Paul Backus wrote:


 In Phobos, we work around problems like this by creating 
 separate `version (StdDdoc)` blocks, which are only used to 
 generate documentation and never compiled. It should be 
 possible to do something similar for druntime. (`version 
 (CoreDdoc)`, maybe?)


Oh, I see CoreDdoc is already implemented in druntime! Thanks, 
I'll try to suggest PR
Mar 23
parent reply Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Monday, 23 March 2026 at 17:50:27 UTC, Denis Feklushkin wrote:


 Oh, I see CoreDdoc is already implemented in druntime! Thanks, 
 I'll try to suggest PR


https://github.com/dlang/dmd/pull/22805
Mar 24
parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
Brings out the implementation of Thread class into OS-specific 
modules

https://github.com/dlang/dmd/pull/23150
Jun 10
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
https://github.com/dlang/dmd/pull/22801
Mar 23