www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Druntime without pthreads?

reply Severin Teona <teona.severin9 gmail.com> writes:
Hi guys.

I have a curiosity, regarding [1] - I had encountered some 
"undefined reference" errors when trying to link the druntime 
(compiled for an embedded architecture) without some 
implementation of the POSIX thread calls (and other stuff too).

My curiosity is what would change if I removed from the druntime 
everything that has to do with mutexes or threads. Would it be 
possible for the druntime to run and work properly on a 
microcontroller - where those concepts are not necessary? Could I 
just remove everything about synchronisation from the druntime, 
and classes or Garbage Collector to still work properly?

[1]: 
https://forum.dlang.org/post/erwfgtigvcciohllvaos forum.dlang.org
Oct 20 2020
next sibling parent sarn <sarn theartofmachinery.com> writes:
On Tuesday, 20 October 2020 at 16:58:12 UTC, Severin Teona wrote:

 Hi guys.

 I have a curiosity, regarding [1] - I had encountered some 
 "undefined reference" errors when trying to link the druntime 
 (compiled for an embedded architecture) without some 
 implementation of the POSIX thread calls (and other stuff too).

 My curiosity is what would change if I removed from the 
 druntime everything that has to do with mutexes or threads. 
 Would it be possible for the druntime to run and work properly 
 on a microcontroller - where those concepts are not necessary? 
 Could I just remove everything about synchronisation from the 
 druntime, and classes or Garbage Collector to still work 
 properly?

 [1]: 
 https://forum.dlang.org/post/erwfgtigvcciohllvaos forum.dlang.org


An alternative would be to link to a custom library that 
implements the pthreads ABI, but stubs everything out in a way 
that makes sense on a single-threaded microcontroller.

I wanted to do that once for another project.  I never got it to 
work for unrelated reasons, so I can't say how well the D runtime 
handles it, sorry.  It's probably an easier approach than 
maintaining your own fork of the runtime, though.
Oct 20 2020
prev sibling next sibling parent IGotD- <nise nise.com> writes:
On Tuesday, 20 October 2020 at 16:58:12 UTC, Severin Teona wrote:

 Hi guys.

 I have a curiosity, regarding [1] - I had encountered some 
 "undefined reference" errors when trying to link the druntime 
 (compiled for an embedded architecture) without some 
 implementation of the POSIX thread calls (and other stuff too).

 My curiosity is what would change if I removed from the 
 druntime everything that has to do with mutexes or threads. 
 Would it be possible for the druntime to run and work properly 
 on a microcontroller - where those concepts are not necessary? 
 Could I just remove everything about synchronisation from the 
 druntime, and classes or Garbage Collector to still work 
 properly?

 [1]: 
 https://forum.dlang.org/post/erwfgtigvcciohllvaos forum.dlang.org


Yes, you can stub the thread and mutex interfaces. You will of 
course not be able use that or any part of the library that uses 
threads  but you will be able to get to the main entry point and 
run a single threaded D program.

This is something we would want with the druntime API change, a 
stub that people can use when they don't need the functionality 
or as a starting point for implementing your own version.
Oct 20 2020
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On Tuesday, 20 October 2020 at 16:58:12 UTC, Severin Teona wrote:

 Hi guys.

 I have a curiosity, regarding [1] - I had encountered some 
 "undefined reference" errors when trying to link the druntime 
 (compiled for an embedded architecture) without some 
 implementation of the POSIX thread calls (and other stuff too).


First, keep in mind that druntime and Phobos depends heavily on 
the C standard library, the Posix APIs, Windows APIs and other 
platform specific APIs. There's no list of what features or APIs 
need to be supported by a platform. There's no general concept of 
optional platform features, i.e. druntime will not automatically 
adopt if your platform doesn't support a specific feature (like 
threads). For example, on iOS (and related platforms) 
`std.process` is not supported (because you're not allowed to 
call `fork`). This is just hardcoded: if the platform is iOS, 
don't provide `std.process`.

What I'm saying, if you modify druntime to remove threads and 
locks, and resolve your undefined references, you might end up 
with new undefined references for other symbols.


 My curiosity is what would change if I removed from the 
 druntime everything that has to do with mutexes or threads. 
 Would it be possible for the druntime to run and work properly 
 on a microcontroller - where those concepts are not necessary? 
 Could I just remove everything about synchronisation from the 
 druntime, and classes or Garbage Collector to still work 
 properly?


The garbage collector will probably work (if you remove the 
interaction with threads from it). Classes are a bit more 
complicated, they have a hidden monitor field [1]. There's also 
the concept of synchronized classes [2]. There's also the 
`synchronized` statement [3]. All these depend on 
mutex/monitors/locks in some form (I don't know exactly how the 
implementation works). Hopefully it should be fine as long as 
your code doesn't use the `synchronized` statement or 
synchronized classes. But all classes do come with a hidden 
monitor field.

[1] https://dlang.org/spec/abi.html#classes
[2] https://dlang.org/spec/class.html#synchronized-classes
[3] https://dlang.org/spec/statement.html#synchronized-statement

--
/Jacob Carlborg
Oct 21 2020
prev sibling parent reply Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Tuesday, 20 October 2020 at 16:58:12 UTC, Severin Teona wrote:


 My curiosity is what would change if I removed from the 
 druntime everything that has to do with mutexes or threads.


Nothing if you don't plan to use multithreading.

I temporary disabled threading and appropriate unittests from my 
fork of druntime without any problem.


 Would it be possible for the druntime to run and work properly 
 on a microcontroller - where those concepts are not necessary?


Sure


 Could I just remove everything about synchronisation from the 
 druntime, and classes or Garbage Collector to still work 
 properly?


Yes
Oct 21 2020
parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Wednesday, 21 October 2020 at 16:04:20 UTC, Denis Feklushkin 
wrote:

 On Tuesday, 20 October 2020 at 16:58:12 UTC, Severin Teona 
 wrote:


 My curiosity is what would change if I removed from the 
 druntime everything that has to do with mutexes




As I remember, your plan is to use some type of RTOS. I am pretty 
sure what any RTOS provides, at least, mutexes.
Oct 21 2020