address for the
breakpoint.
Has anybody else noticed a problem with breakpoints for worker
threads? Or should I be looking at something else?
(Note, I can break at _Dmain and see things OK, it's just once
the middleware has taken over that I can't seem to look at the
running code.)
https://issues.dlang.org/show_bug.cgi?id=24260
Issue ID: 24260
Summary: GC creates too many threads when running with
restricted CPU affinity
Product: D
Version: D2
Hardware: All
OS: All
Status
On Monday, 28 August 2023 at 22:43:56 UTC, Ali Çehreli wrote:
On 8/28/23 15:37, j...@bloow.edu wrote:
> Basically everything is hard coded to use totalCPU's
parallel() is a function that dispatches to a default TaskPool
object, which uses totalCPUs. It's convenient but as you say,
not all
On 29.08.23 00:37, j...@bloow.edu wrote:
Well, I have 32 cores so that would spawn 64-1 threads with hyper
threading so not really a solution as it is too many simultaneous downs
IMO.
"These properties get and set the number of worker threads in the
TaskPool instance returned by tas
On 8/28/23 15:37, j...@bloow.edu wrote:
> Basically everything is hard coded to use totalCPU's
parallel() is a function that dispatches to a default TaskPool object,
which uses totalCPUs. It's convenient but as you say, not all problems
should use it.
In such cases, you would create your
ll workloads where task / thread switching
would be a big performance problem (I guess). So in your case a
work unit size of 1 should be good.
Did you try this already?
Kind regards,
Christian
Well, I have 32 cores so that would spawn 64-1 threads with hyper
threading so not r
On 26.08.23 05:39, j...@bloow.edu wrote:
On Friday, 25 August 2023 at 21:31:37 UTC, Ali Çehreli wrote:
On 8/25/23 14:27, j...@bloow.edu wrote:
> "A work unit is a set of consecutive elements of range to be
processed
> by a worker thread between communication with any other
thread. The
> number
).
Ultimately this seems like a design flaw in ThreadPool which
should auto rebalance the threads and not treat the number of
threads as identical to the worker unit size(well,
length/workerunitsize).
e.g., suppose we have 1000 tasks and set worker unit size to 100.
This gives 10 workers and 10
On Friday, 25 August 2023 at 21:31:37 UTC, Ali Çehreli wrote:
On 8/25/23 14:27, j...@bloow.edu wrote:
> "A work unit is a set of consecutive elements of range to be
processed
> by a worker thread between communication with any other
thread. The
> number of elements processed per work unit is
On Wednesday, 23 August 2023 at 13:03:36 UTC, Joe wrote:
to download files from the internet.
Are they particularly big files? You might consider using one of
the other libs that does it all in one thread. (i ask about size
cuz mine ive never tested doing big files at once, i usually use
it
On 8/25/23 14:27, j...@bloow.edu wrote:
> "A work unit is a set of consecutive elements of range to be processed
> by a worker thread between communication with any other thread. The
> number of elements processed per work unit is controlled by the
> workUnitSize parameter. "
>
> So the question
On Wednesday, 23 August 2023 at 14:43:33 UTC, Sergey wrote:
On Wednesday, 23 August 2023 at 13:03:36 UTC, Joe wrote:
I use
foreach(s; taskPool.parallel(files, numParallel))
{ L(s); } // L(s) represents the work to be done.
If you make for example that L function return “ok” in case
file
On Wednesday, 23 August 2023 at 14:43:33 UTC, Sergey wrote:
On Wednesday, 23 August 2023 at 13:03:36 UTC, Joe wrote:
I use
foreach(s; taskPool.parallel(files, numParallel))
{ L(s); } // L(s) represents the work to be done.
If you make for example that L function return “ok” in case
file
On Wednesday, 23 August 2023 at 13:03:36 UTC, Joe wrote:
I use
foreach(s; taskPool.parallel(files, numParallel))
{ L(s); } // L(s) represents the work to be done.
If you make for example that L function return “ok” in case file
successfully downloaded, you can try to use TaskPool.amap.
The
I use
foreach(s; taskPool.parallel(files, numParallel))
{ L(s); } // L(s) represents the work to be done.
to download files from the internet.
Everything works. The issue is this:
the foreach will download 8 files at once. BUT it will not start
the next batch of 8 *until* ALL of the previous
https://forum.dlang.org/post/eeqqmlojlniiihgyb...@forum.dlang.org
On Sunday, 16 January 2022 at 09:38:52 UTC, Bagomot wrote:
The program does nothing probably because of that continue. (?)
No, it does work inside the loop.
So, the event loop is in a separate thread. What should happen
when
On 3/21/23 22:30, Tim wrote:
> to make a simple multi-threading application.
Unless there is a reason not to, I recommend std.concurrency and
std.parallelism modules. They are different but much more simpler
compared to the low-level core.thread.
> args_copy = args; //Why program name
On Wednesday, 22 March 2023 at 07:16:43 UTC, Kagamin wrote:
static is thread local by default.
```
module main;
import app;
import core.thread;
int main(string[] args)
{
static shared int result;
static shared string[] args_copy;
static void app_thread()
{
App app
On Wednesday, 22 March 2023 at 07:16:43 UTC, Kagamin wrote:
static is thread local by default.
```
module main;
import app;
import core.thread;
int main(string[] args)
{
static shared int result;
static shared string[] args_copy;
static void app_thread()
{
App app
static is thread local by default.
```
module main;
import app;
import core.thread;
int main(string[] args)
{
static shared int result;
static shared string[] args_copy;
static void app_thread()
{
App app = new App();
result = app.run(args_copy);
}
Hello! I am trying to make a simple multi-threading application.
But I get an error when I run the main thread of the program in a
thread. The question is: "How to pass arguments from the main
thread to the newly created thread of itself". Here is a piece of
code:
module main;
import app;
---
@RazvanN7 created dlang/dmd pull request #14907 "Fix Issue 19978 - D sometimes
just crashes on exit with daemon threads" fixing this issue:
- Fix Issue 19978 - D sometimes just crashes on exit with daemon threads
https://github.com/dlang/dmd/pull/14907
--
https://issues.dlang.org/show_bug.cgi?id=19978
--- Comment #5 from FeepingCreature ---
How do you run module dtors without stopping the threads anyways? I don't see
how that'd ever be safe.
--
erm>os_mem_unmap) Why not let the OS handle
> the frees?
The problem is that we have (shared) static constructors/destructors to worry
about. Currently, I haven't found any information about the behavior of daemon
threads in the presence of module constructors, however, my expectation is that
the
https://issues.dlang.org/show_bug.cgi?id=22358
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P2
--
https://issues.dlang.org/show_bug.cgi?id=19978
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P2
--
https://issues.dlang.org/show_bug.cgi?id=16324
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P2
--
https://issues.dlang.org/show_bug.cgi?id=19397
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P3
--
https://issues.dlang.org/show_bug.cgi?id=13166
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P4
--
https://issues.dlang.org/show_bug.cgi?id=21066
Andrej Mitrovic changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Monday, 27 December 2021 at 10:59:07 UTC, Ali Çehreli wrote:
...my DConf Online 2020 presentation here:
https://dconf.org/2020/online/#ali1
Ali
Hey, that is a really great presentation!
Many more people should watch it, and learn ;-)
The program does nothing probably because of that continue. (?)
No, it does work inside the loop.
So, the event loop is in a separate thread. What should happen
when the events trigger? Do you want this thread to handle the
events or should this thread send a > message to the main
thread
On 1/12/22 00:50, Bagomot wrote:
> If I change the run method of the Guard class so that it starts a new
> thread, the program just does nothing:
> ```d
> public void run() {
> spawn((shared EventLoop eventLoop) {
> while ((cast() eventLoop).loop()) {
> continue;
The
On Saturday, 15 January 2022 at 19:07:20 UTC, frame wrote:
On Wednesday, 12 January 2022 at 08:50:09 UTC, Bagomot wrote:
Why? What am I doing wrong?
I guess your main() exits and just ends all threads?
No, the program continues to run. And I tested it with while in
main.
On Wednesday, 12 January 2022 at 08:50:09 UTC, Bagomot wrote:
Why? What am I doing wrong?
I guess your main() exits and just ends all threads?
On Wednesday, 12 January 2022 at 08:50:09 UTC, Bagomot wrote:
Good day! I keep giving rise to problems.
Above, Tejas helped me a lot, but still doesn't work.
I gave up using the fswatch library, thinking that the problem
was in it.
Now trying to do it using libasync.
Here is the code that
Good day! I keep giving rise to problems.
Above, Tejas helped me a lot, but still doesn't work.
I gave up using the fswatch library, thinking that the problem
was in it.
Now trying to do it using libasync.
Here is the code that runs on the main thread, it blocks further
actions on that
Thanks! It works.
Perhaps there will still be difficulties, I will write here.
On Tuesday, 28 December 2021 at 16:29:05 UTC, Bagomot wrote:
I can't do it according to your example, my Watcher list fills
up at runtime.
Yes, it's possible to do it at runtime as well(it already _was_
happening at runtime), although I'll be using a `cast` for
convenience now.
```d
On Tuesday, 28 December 2021 at 15:42:04 UTC, Tejas wrote:
On Tuesday, 28 December 2021 at 14:19:46 UTC, Bagomot wrote:
On Monday, 27 December 2021 at 10:59:07 UTC, Ali Çehreli wrote:
On 12/27/21 1:33 AM, Bagomot wrote:
> separate thread, without blocking the main one.
I think you can use
On Tuesday, 28 December 2021 at 14:19:46 UTC, Bagomot wrote:
On Monday, 27 December 2021 at 10:59:07 UTC, Ali Çehreli wrote:
On 12/27/21 1:33 AM, Bagomot wrote:
> separate thread, without blocking the main one.
I think you can use std.concurrency there. I have a chapter
here:
On Monday, 27 December 2021 at 10:59:07 UTC, Ali Çehreli wrote:
On 12/27/21 1:33 AM, Bagomot wrote:
> separate thread, without blocking the main one.
I think you can use std.concurrency there. I have a chapter
here:
http://ddili.org/ders/d.en/concurrency.html
Look for 'struct Exit' to
On 12/27/21 1:33 AM, Bagomot wrote:
> separate thread, without blocking the main one.
I think you can use std.concurrency there. I have a chapter here:
http://ddili.org/ders/d.en/concurrency.html
Look for 'struct Exit' to see how the main thread signals workers to
stop running.
And some
the main thread of the program.
I tried to get my head around Thread and Fiber but still didn't
figure out how to properly start and manage threads. I have using
Thread turns it into a zombie when the main thread of the program
ends.
I will not even write my code here, because it is at the level
https://issues.dlang.org/show_bug.cgi?id=22358
thomas.bock...@gmail.com changed:
What|Removed |Added
CC||thomas.bock...@gmail.com
---
https://issues.dlang.org/show_bug.cgi?id=22358
--- Comment #2 from Ali Cehreli ---
This is likely the same as 18063.
--
https://issues.dlang.org/show_bug.cgi?id=22358
Ali Cehreli changed:
What|Removed |Added
CC||acehr...@yahoo.com
See Also|
https://issues.dlang.org/show_bug.cgi?id=22358
Richard Cattermole changed:
What|Removed |Added
CC||alphaglosi...@gmail.com
--- Comment #1
https://issues.dlang.org/show_bug.cgi?id=22358
Issue ID: 22358
Summary: Allocations from foreign threads lead to crash
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: critical
On Friday, 10 September 2021 at 12:59:08 UTC, bauss wrote:
It's just used to speed-up the GC.
Yeah, I got the point, but to be absolutely honest,
I (>20 years of C coding) do not like GC as such.
I believe manual free() is not that 'hard'.
And one must still release other resources.
(in C I
On Friday, 10 September 2021 at 12:46:36 UTC, eugene wrote:
On Friday, 10 September 2021 at 12:10:58 UTC, Adam D Ruppe
wrote:
btw why do the threads cause you trouble?
Well... probably it is subjective thing -
just do not 'like' when a program is doing something
that is not explicitly in it's
On Friday, 10 September 2021 at 12:10:58 UTC, Adam D Ruppe wrote:
btw why do the threads cause you trouble?
Well... probably it is subjective thing -
just do not 'like' when a program is doing something
that is not explicitly in it's source (I am C coder, you guessed).
More specifically - I
btw why do the threads cause you trouble?
On Friday, 10 September 2021 at 11:53:04 UTC, eugene wrote:
On Friday, 10 September 2021 at 11:32:02 UTC, Adam D Ruppe
wrote:
You either pass as an argument *to your application*
--DRT-gcopt=parallel:0
oops... :)
ps xH | grep [e]cho
5727 pts/14 S+ 0:13 ./echo-server
On 9/10/21 7:47 AM, eugene wrote:
On Friday, 10 September 2021 at 11:09:10 UTC, bauss wrote:
--DRT-gcopt=parallel:2 on the command line. A value of 0 disables
parallel marking completely.
but it does not:
make -f Makefile-dmd
dmd --DRT-gcopt=parallel:0 engine/*.d common-sm/*.d server-sm/*.d
On Friday, 10 September 2021 at 11:32:02 UTC, Adam D Ruppe wrote:
You either pass as an argument *to your application*
--DRT-gcopt=parallel:0
oops... :)
On Friday, 10 September 2021 at 11:09:10 UTC, bauss wrote:
--DRT-gcopt=parallel:2 on the command line. A value of 0
disables parallel marking completely.
but it does not:
make -f Makefile-dmd
dmd --DRT-gcopt=parallel:0 engine/*.d common-sm/*.d server-sm/*.d
pool.d echo_server.d
On Friday, 10 September 2021 at 09:27:49 UTC, eugene wrote:
What are these extra threads for?
GC?
So I think it is **very aggressive usage** of DList that causes
this.
Yeah, in newer versions, when the garbage collector does its
first collect, it spawns some helper threads to speed up its
On Friday, 10 September 2021 at 11:09:10 UTC, bauss wrote:
Here's the specific change:
https://dlang.org/changelog/2.087.0.html#gc_parallel
thanx a lot!
On Friday, 10 September 2021 at 10:20:52 UTC, drug wrote:
It is off-topic a bit
I am newbie - have been learning D for about 2 months or so.
I understand that my question is not about the language itself,
just picked forum for new users.
but I think none can compare gdc 4.9.2 to
same
On Friday, 10 September 2021 at 11:20:10 UTC, eugene wrote:
same picture with gdc 8.4.0 - one thread, no pthread_create()
behind the scenes.
GDC is stuck on a much older version of D. Iain has backported
some bugfixes and optimizations, but featurewise it's mostly D
2.076. This is because
On Friday, 10 September 2021 at 10:39:48 UTC, Basile B. wrote:
On Friday, 10 September 2021 at 09:27:49 UTC, eugene wrote:
Here is test program (which is using DList aggressively)
[...]
Can this (really unwanted) behavior be disabled in DMD?
I do not want to have multiple threads,
a program
On Friday, 10 September 2021 at 09:27:49 UTC, eugene wrote:
Here is test program (which is using DList aggressively)
[...]
Can this (really unwanted) behavior be disabled in DMD?
I do not want to have multiple threads,
a program (real program, not the test above) has to be
single-threaded
10.09.2021 12:27, eugene пишет:
//import std.container.dlist; // dmd (v2.097.2)
import std.container: DList; // gdc (4.9.2)
It is off-topic a bit but I think none can compare gdc 4.9.2 to dmd
2.097.2 because gdc has older version than dmd. I would compare gdc to
appropriate dmd version,
with dmd, program creates 3 additional threads:
@dexp ~ $ ps xH | grep [t]est
3839 pts/12 Rl+0:00 ./test
3839 pts/12 Sl+0:00 ./test
3839 pts/12 Sl+0:00 ./test
3839 pts/12 Sl+0:00 ./test
What are these extra threads for?
To work with list (which is strange)???
GC
On Friday, 30 July 2021 at 23:48:41 UTC, solidstate1991 wrote:
Info on it is quite scarce and a bit confusing. If I unregister
from the RT, will that mean it'll be GC independent, or will
have other consequences too?
The consequence is that the stack memory of that thread isn't
traced, so
On Friday, 30 July 2021 at 23:48:41 UTC, solidstate1991 wrote:
I'm doing some audio-related work, and one thing I need is to
unregister from (and maybe later temporarily re-register to)
the GC, since it would cause some issues,
GC + audio is only a problem if its pauses (e.g in the audio
On Friday, 30 July 2021 at 23:48:41 UTC, solidstate1991 wrote:
I'm doing some audio-related work, and one thing I need is to
unregister from (and maybe later temporarily re-register to)
the GC, since it would cause some issues, and it would be nice
if I still could use the GC during disk
I'm doing some audio-related work, and one thing I need is to
unregister from (and maybe later temporarily re-register to) the
GC, since it would cause some issues, and it would be nice if I
still could use the GC during disk operations, etc.
Info on it is quite scarce and a bit confusing. If
https://issues.dlang.org/show_bug.cgi?id=1085
Andrew Edwards changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Monday, 1 March 2021 at 09:03:32 UTC, rikki cattermole wrote:
So it is debatable if it is a good idea to get rid of them once
done (even if delayed).
Makes sense, Thanks a lot for the quick help!
On 01/03/2021 8:02 PM, Keivan Shah wrote:
If possible, Can you also help me understand that why are the threads
not despawned once the GC is done collecting in this example?
There was a PR about this ages ago.
But one thing to consider is that keeping threads around not doing
anything
/dlang.org/spec/garbage.html#gc_parallel). If
possible, Can you also help me understand that why are the
threads not despawned once the GC is done collecting in this
example?
Do you still get them when you call your app like this?
./app --DRT-gcopt=parallel:0
I had recently updated my dmd version to latest, i.e from 2.076.1
(I know, sorry) to 2.095.0 and suddenly my code has started
spawning extra threads which were not there before with no
obvious reasons, after trying to simplify and identify the cause
as much as possible, I have come up
https://issues.dlang.org/show_bug.cgi?id=21066
--- Comment #2 from FeepingCreature ---
Readable version:
> A signal may be process-directed or thread-directed. [...]
> A thread-directed signal is one that is targeted at a specific thread. A
> signal may be
> thread-directed because it was
https://issues.dlang.org/show_bug.cgi?id=21066
FeepingCreature changed:
What|Removed |Added
CC||default_357-l...@yahoo.de
--- Comment #1
https://issues.dlang.org/show_bug.cgi?id=21066
Issue ID: 21066
Summary: Druntime SIGSEGV / SIGBUS unittest signal handler
should emit the stack trace for all threads
Product: D
Version: D2
Hardware: All
OS
On Wednesday, 1 July 2020 at 07:52:28 UTC, AB wrote:
Hello. I am unsure how to proceed about printing progress in my
program.
Suppose the program is processing a very big file and is
iterating the file's bytes using a for loop. The processing
takes several minutes and I want a progress
= input.length;
for (ulong i = 0; i < fileSize; ++i)
{
// ...
}
If you can only update the progress between iterations I don't
see why you would use threads here. A timer should suffice:
import std.datetime.stopwatch;
MmFile input = new MmFile(/* ... */);
ul
Hello. I am unsure how to proceed about printing progress in my
program.
Suppose the program is processing a very big file and is
iterating the file's bytes using a for loop. The processing takes
several minutes and I want a progress percentage be printed every
2 seconds in this manner:
https://issues.dlang.org/show_bug.cgi?id=19861
--- Comment #10 from Dlang Bot ---
dlang/druntime pull request #3107 "[dmd-cxx] fix Issue 19861 - core.cpuid
reports the wrong number of threads" was merged into dmd-cxx:
- d989df32ae1645203ceb24ccfa62ddfd46f078d4 by Rainer Schuetze:
https://issues.dlang.org/show_bug.cgi?id=19978
--- Comment #3 from FeepingCreature ---
Okay, got it.
The problem is with a daemon thread, D doesn't join it when shutting down. As a
result, the GC shutdown sequence deletes the thread's memory right under it.
Why do we do this anyway?
On Thu, 2020-04-23 at 14:41 +0300, drug via Digitalmars-d-learn wrote:
>
[…]
> Did you try `dub test -- -s`?
Oh f###, that is about the only combination I didn't try. :-(
Thanks. Problem solved. :-)
Not sure about the Fixture proposal, I will research and cogitate
further.
--
Russel.
after main. However I
am using unit-threaded, not for the threads but because it is great for
a whole load of other reasons. In fact the threads are becoming a
problem.
As far as I can tell main is terminating before all the tests are
complete which means the shared static destructor is executing
23.04.2020 14:41, drug пишет:
terminate it after in ``
terminate it after in `shutdown()`
-threaded, not for the threads but because it is great for
a whole load of other reasons. In fact the threads are becoming a
problem.
As far as I can tell main is terminating before all the tests are
complete which means the shared static destructor is executing before
all the tests are complete.
To test
|--- |FIXED
--- Comment #2 from Dlang Bot ---
dlang/druntime pull request #2933 "fix Issue 20567 - GC should not start
threads for parallel marking in simple programs" was merged into master:
- 3d44d2affda45e638ed52b0c9658435b3418d7f8 by Rainer Schuetze:
fix Issue 20567 -
---
@rainers created dlang/druntime pull request #2933 "fix Issue 20567 - GC should
not start threads for parallel marking in simple programs" fixing this issue:
- fix Issue 20567 - GC should not start threads for parallel marking in simple
programs
avoid collection when there is no small/
https://issues.dlang.org/show_bug.cgi?id=20567
Issue ID: 20567
Summary: GC should not start threads for parallel marking in
simple programs
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
On 2/2/20 12:13 PM, cc wrote:
On Friday, 31 January 2020 at 15:47:26 UTC, Steven Schveighoffer wrote:
You could use RefCounted to build a struct that then is sendable with
the data you need. RefCounted allocates using C malloc, not the GC.
Thanks for the tips. How exactly would I go about
On Friday, 31 January 2020 at 15:47:26 UTC, Steven Schveighoffer
wrote:
You could use RefCounted to build a struct that then is
sendable with the data you need. RefCounted allocates using C
malloc, not the GC.
Thanks for the tips. How exactly would I go about sending a
RefCounted value?
On 1/31/20 2:14 AM, cc wrote:
On Wednesday, 29 January 2020 at 21:10:53 UTC, Steven Schveighoffer wrote:
I'm pretty sure std.concurrency uses Variant to pass message data,
which boxes when it gets over a certain size. You are probably
crossing that threshold.
The allocations should level out
On Friday, 31 January 2020 at 07:14:30 UTC, cc wrote:
On Wednesday, 29 January 2020 at 21:10:53 UTC, Steven
Schveighoffer wrote:
I'm pretty sure std.concurrency uses Variant to pass message
data, which boxes when it gets over a certain size. You are
probably crossing that threshold.
The
On Wednesday, 29 January 2020 at 21:10:53 UTC, Steven
Schveighoffer wrote:
I'm pretty sure std.concurrency uses Variant to pass message
data, which boxes when it gets over a certain size. You are
probably crossing that threshold.
The allocations should level out eventually when the GC starts
On 1/29/20 2:48 PM, cc wrote:
Given the sample program at https://pastebin.com/u9sSNtj7
I'm experiencing GC allocations with every call to std.concurrency.send
when sending larger messages (e.g. multiple ulongs). These do not occur
when sending uints in comparison, in the provided example.
Given the sample program at https://pastebin.com/u9sSNtj7
I'm experiencing GC allocations with every call to
std.concurrency.send when sending larger messages (e.g. multiple
ulongs). These do not occur when sending uints in comparison, in
the provided example.
For example, when the
https://issues.dlang.org/show_bug.cgi?id=13330
moonlightsenti...@disroot.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=5488
berni44 changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=19978
Gregor Mückl changed:
What|Removed |Added
CC|gregormue...@gmx.de |
Severity|normal
1 - 100 of 915 matches
Mail list logo
