On Friday, 15 October 2021 at 03:35:44 UTC, jfondren wrote:
The book, "The Go Programming Language" has this simple
goroutine example:
[...]
Here is a similar implementation using the concurrency library:
```d
import concurrency;
import concurrency.stream;
import concurrency.sender : justFro
On 10/15/21 10:01 AM, Ali Çehreli wrote:
> writefln!"\rFibonacci(%d) = %d"(n, fibN);
That '\r' bothered me because the actual work needs to know what the
spinner is doing to clear its remaining character.
I would expect the original go code had the same problem.
-Steve
On 10/14/21 8:54 PM, Ali Çehreli wrote:
>writefln!"\rFibonacci(%d) = %d"(n, fibN);
That '\r' bothered me because the actual work needs to know what the
spinner is doing to clear its remaining character.
>receiveTimeout(delay,
> (OwnerTerminated msg) {
And th
On 10/14/21 11:35 PM, jfondren wrote:
The book, "The Go Programming Language" has this simple goroutine example:
```go
func main() {
go spinner(100 * time.Millisecond)
const n = 45
fibN := fib(n) // slow
fmt.Printf("\rFibonacci(%d) = %d\n", n, fibN)
}
func spinner(delay time
On Friday, 15 October 2021 at 03:54:17 UTC, Ali Çehreli wrote:
On 10/14/21 8:35 PM, jfondren wrote:
[...]
Here is one that uses receiveTimeout and OwnerTerminated:
import std.stdio;
import std.concurrency;
import core.thread;
void main() {
spawnLinked(&spinner, 100.msecs);
enum n = 45;
On 10/14/21 9:17 PM, jfondren wrote:
On Friday, 15 October 2021 at 03:54:17 UTC, Ali Çehreli wrote:
On 10/14/21 8:35 PM, jfondren wrote:
The book, "The Go Programming Language" has this simple goroutine
example:
Here is one that uses receiveTimeout and OwnerTerminated:
Very nice, replacing
On Friday, 15 October 2021 at 03:54:17 UTC, Ali Çehreli wrote:
On 10/14/21 8:35 PM, jfondren wrote:
The book, "The Go Programming Language" has this simple
goroutine example:
Here is one that uses receiveTimeout and OwnerTerminated:
Very nice, replacing Thread.sleep with receiveTimeout and
On 10/14/21 8:35 PM, jfondren wrote:
The book, "The Go Programming Language" has this simple goroutine example:
Here is one that uses receiveTimeout and OwnerTerminated:
import std.stdio;
import std.concurrency;
import core.thread;
void main() {
spawnLinked(&spinner, 100.msecs);
enum n =
The book, "The Go Programming Language" has this simple goroutine
example:
```go
func main() {
go spinner(100 * time.Millisecond)
const n = 45
fibN := fib(n) // slow
fmt.Printf("\rFibonacci(%d) = %d\n", n, fibN)
}
func spinner(delay time.Duration) {
for {
for _, r :=
On Friday, 27 December 2019 at 07:06:52 UTC, mipri wrote:
On Friday, 27 December 2019 at 06:08:16 UTC, Marcone wrote:
import std;
import core.thread;
auto threading(lazy void fun){ return
task!fun().executeInNewThread(); }
void main(){
threading(writeln("Hello World!"));
On Friday, 27 December 2019 at 07:06:52 UTC, mipri wrote:
On Friday, 27 December 2019 at 06:08:16 UTC, Marcone wrote:
import std;
import core.thread;
auto threading(lazy void fun){ return
task!fun().executeInNewThread(); }
void main(){
threading(writeln("Hello World!"));
On Friday, 27 December 2019 at 06:08:16 UTC, Marcone wrote:
import std;
import core.thread;
auto threading(lazy void fun){ return
task!fun().executeInNewThread(); }
void main(){
threading(writeln("Hello World!"));
}
I want to create a function threading() to run some f
import std;
import core.thread;
auto threading(lazy void fun){ return
task!fun().executeInNewThread(); }
void main(){
threading(writeln("Hello World!"));
}
I want to create a function threading() to run some function in
other threading, but I get this error bellow. How
Well, if the code is too complex to debug, the usual solution is
to try simpler code and see if it works.
there anything obviously wrong with the variable declarations in
the code sample? It looks like having a console output window in
addition to just the GUI is having some sort of effect on
threading, sharing or timing.
On Sunday, 7 April 2019 at 14:49:20 UTC, Archie Allison wrote:
The codebase is a reasonable size so too big (and proprietary)
to share.
You can reduce it to a minimal example that doesn't work. Static
variables are thread local by default in D unless they are marked
as shared or __gshared.
On Sunday, 7 April 2019 at 14:08:07 UTC, Archie Allison wrote:
This generally works OK when tied to a Console but when link
options are changed to be SUBSYSTEM:WINDOWS and
ENTRY:mainCRTStartup it rarely does.
Manually setting the entry point sounds problematic if no other
precautions are ta
On Sunday, 7 April 2019 at 17:52:40 UTC, Mike Wey wrote:
How are you using the GUI, GTK is not thread safe, all gui
function calls should be made from the GUI thread.
Last time i checked threadsEnter and threadsLeave didn't work
properly on windows.
All GUI updates are sent from a worker
On 07-04-2019 16:49, Archie Allison wrote:
The codebase is a reasonable size so too big (and proprietary) to share.
It's always run with a GUI (GTKD), it's just the difference in linking
so launching (a)GUI + attached console for stdout.writeln vs. (b)just
the GUI window. There's nothing I'd e
On Sunday, 7 April 2019 at 14:35:24 UTC, Doc Andrew wrote:
When you say it "rarely works" when run as a GUI app (vs
console), it makes me think that there's probably a race
condition going on, and the extra context switching that takes
place in GUI mode makes it more likely. I haven't tried it
here I may have misunderstood the
threading and shared-memory design of D or what I can look at?
When you say it "rarely works" when run as a GUI app (vs
console), it makes me think that there's probably a race
condition going on, and the extra context switching that takes
place
port is in thread local
storage. As a hardware resource, I wasn't sure if this matters.
I've tried casting to a shared object so it no longer appears in
the -vtls list, with no difference.
Does anyone have ideas about where I may have misunderstood the
threading and shared-memory d
e messages will
> > be passed directly instead of via networking.
>
> What you're describing here is not actually multi-threading, it's
> multi-process…ing. The keyword you're looking for is "inter-process
> communication".
>
> You have a huge range
ually multi-threading, it's
multi-process…ing. The keyword you're looking for is
"inter-process communication".
You have a huge range of possible options for implementing this.
Your decision would depend on your operating system, your
existing implementation with sockets
touched multi-threading in college. Some
suggestions?
On 01/04/2016 06:31 AM, TheDGuy wrote:
> I tried it with "std.concurrency" like this:
>
> bool drawCallback(Scoped!Context cr, Widget widget){
> writeln("init");
> spawn(&render, cr, widget);
The first parameter to render() is Scoped!Context but render() takes a
Context:
> void rend
On Monday, 4 January 2016 at 18:04:34 UTC, TheDGuy wrote:
On Monday, 4 January 2016 at 17:33:28 UTC, Gerald wrote:
On Monday, 4 January 2016 at 16:13:50 UTC, TheDGuy wrote:
[...]
Yes, you need it. The extern (C) function is what GDK invokes
on idle. In any GUI application there is a lot of i
On Monday, 4 January 2016 at 17:33:28 UTC, Gerald wrote:
On Monday, 4 January 2016 at 16:13:50 UTC, TheDGuy wrote:
[...]
Yes, you need it. The extern (C) function is what GDK invokes
on idle. In any GUI application there is a lot of idle time
waiting for events, what the addThreadIdle allows
just as easily be a resultset
from a long running database query, a complicated mathematical
expression, etc. Hopefully the previous explanation helps you
understand what the callback is doing.
You can see a more real world example of GtkD multi-threading in
this application I wrote called Visu
I wrote a demo for GtkD showing how multi-threading and D work
together, it's in the demos/gtkD/DemoMultithread folder of
GtkD, hopefully it will be helpful. However this example it is
based on using the GTk threadIdle callback which is generally
preferred over the locking methods you
/software/gnome-desktop/gtk-thread-awareness
Okay, so i have to do it like this on every function i use from
GTKD?
threadsInit();
threadsEnter();
GtkAllocation size;
widget.getAllocation(size);
threadsLeave();
I wrote a demo for GtkD showing how multi-threading and D work
together, it's i
On Monday, 4 January 2016 at 15:07:12 UTC, Luis wrote:
On Monday, 4 January 2016 at 14:31:04 UTC, TheDGuy wrote:
[...]
Before doing anything with threads and GTK, you should read
this :
http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness
Okay, so i have
On Monday, 4 January 2016 at 14:31:04 UTC, TheDGuy wrote:
Hello,
i use GTKD to draw some stuff on a DrawingArea. Because it
needs some time to calculate i want to outsource those
calculation so that the GUI doesn't freeze.
I tried it with "std.concurrency" like this:
bool drawCallback(Scope
Hello,
i use GTKD to draw some stuff on a DrawingArea. Because it needs
some time to calculate i want to outsource those calculation so
that the GUI doesn't freeze.
I tried it with "std.concurrency" like this:
bool drawCallback(Scoped!Context cr, Widget widget){
writeln("init");
On Friday, 9 October 2015 at 04:04:42 UTC, bitwise wrote:
Ah, I see. I thought you meant illegal meant it won't compile.
Wouldn't it be more correct to say that it's undefined
behaviour?
I's probably not as undefined as in C case, i.e. it doesn't break
safety guarantees, only the application'
On Thursday, 8 October 2015 at 20:42:46 UTC, Kagamin wrote:
On Thursday, 8 October 2015 at 13:44:46 UTC, bitwise wrote:
That still doesn't explain what you mean about it being
illegal in other languages or why you brought up C# in the
first place.
Illegal means the resulting program behaves i
On Thursday, 8 October 2015 at 13:44:46 UTC, bitwise wrote:
That still doesn't explain what you mean about it being illegal
in other languages or why you brought up C# in the first place.
Illegal means the resulting program behaves incorrectly,
potentially leading to silent failures and data c
On Thursday, 8 October 2015 at 10:11:38 UTC, Kagamin wrote:
On Thursday, 8 October 2015 at 02:31:24 UTC, bitwise wrote:
If you have System.Collections.Generic.List(T) static class
member, there is nothing wrong with using it from multiple
threads like this:
The equivalent of your D example wo
On Thursday, 8 October 2015 at 02:31:24 UTC, bitwise wrote:
If you have System.Collections.Generic.List(T) static class
member, there is nothing wrong with using it from multiple
threads like this:
The equivalent of your D example would be
class Foo {
static List numbers = new List();
On Wednesday, 7 October 2015 at 09:09:36 UTC, Kagamin wrote:
On Sunday, 4 October 2015 at 04:24:55 UTC, bitwise wrote:
I use C#(garbage collected) for making apps/games, and while,
_in_theory_, the GC is supposed to protect you from leaks,
memory is not the only thing that can leak. Threads nee
On Sunday, 4 October 2015 at 04:24:55 UTC, bitwise wrote:
I use C#(garbage collected) for making apps/games, and while,
_in_theory_, the GC is supposed to protect you from leaks,
memory is not the only thing that can leak. Threads need to be
stopped, graphics resources need to be released, etc.
On Monday, 5 October 2015 at 20:18:18 UTC, Laeeth Isharc wrote:
On Monday, 5 October 2015 at 17:40:24 UTC, bitwise wrote:
You may be right. I wrote a simple download manager in D using
message passing. It was a little awkward at first, but in
general, the spawn/send/receive API seems very intui
On 10/5/15 1:40 PM, bitwise wrote:
On Monday, 5 October 2015 at 00:23:21 UTC, Jonathan M Davis wrote:
On Sunday, October 04, 2015 14:42:48 bitwise via Digitalmars-d-learn
wrote:
Since D is moving towards a phobos with no GC, what will happen to
things that are classes like Condition and Mutex?
On Monday, 5 October 2015 at 17:40:24 UTC, bitwise wrote:
You may be right. I wrote a simple download manager in D using
message passing. It was a little awkward at first, but in
general, the spawn/send/receive API seems very intuitive. It
feels awkward because the data you're working with is o
On Monday, 5 October 2015 at 00:23:21 UTC, Jonathan M Davis wrote:
On Sunday, October 04, 2015 14:42:48 bitwise via
Digitalmars-d-learn wrote:
Since D is moving towards a phobos with no GC, what will
happen to things that are classes like Condition and Mutex?
Phobos and druntime will always us
On Sunday, October 04, 2015 14:42:48 bitwise via Digitalmars-d-learn wrote:
> Since D is moving towards a phobos with no GC, what will happen
> to things that are classes like Condition and Mutex?
Phobos and druntime will always use the GC for some things, and some things
just plain need classes.
On Wednesday, 30 September 2015 at 10:32:01 UTC, Jonathan M Davis
wrote:
On Tuesday, September 29, 2015 22:38:42 Johannes Pfau via
Digitalmars-d-learn wrote:
[...]
What I took from the answers to that SO question was that in
general, it really doesn't matter whether a condition variable
has
On Tuesday, 29 September 2015 at 23:20:31 UTC, Steven
Schveighoffer wrote:
yeah, that could probably be done. One thing to note is that
these classes are from ages ago (probably close to 10 years).
New API suggestions may be allowed.
-Steve
I'm still thinking about my last rant, here... S
On Tuesday, 29 September 2015 at 19:10:58 UTC, Steven
Schveighoffer wrote:
An object that implements the Monitor interface may not
actually be a mutex. For example, a pthread_cond_t requires a
pthread_mutex_t to operate properly.
Right! I feel like I should have caught the fact that
Conditi
On Friday, 25 September 2015 at 15:19:27 UTC, bitwise wrote:
I know that all global variables are TLS unless explicitly
marked as 'shared', but someone once told me something about
'shared' affecting member variables in that accessing them from
a separate thread would return T.init instead of t
On Tuesday, September 29, 2015 22:38:42 Johannes Pfau via Digitalmars-d-learn
wrote:
> Am Tue, 29 Sep 2015 15:10:58 -0400
> schrieb Steven Schveighoffer :
>
> >
> > > 3) Why do I have to pass a "Mutex" to "Condition"? Why can't I just
> > > pass an "Object"?
> >
> > An object that implements the M
On 9/29/15 4:38 PM, Johannes Pfau wrote:
Am Tue, 29 Sep 2015 15:10:58 -0400
schrieb Steven Schveighoffer :
3) Why do I have to pass a "Mutex" to "Condition"? Why can't I just
pass an "Object"?
An object that implements the Monitor interface may not actually be a
mutex. For example, a pthrea
Am Tue, 29 Sep 2015 15:10:58 -0400
schrieb Steven Schveighoffer :
>
> > 3) Why do I have to pass a "Mutex" to "Condition"? Why can't I just
> > pass an "Object"?
>
> An object that implements the Monitor interface may not actually be a
> mutex. For example, a pthread_cond_t requires a pthread_m
On 9/25/15 11:19 AM, bitwise wrote:
Hey, I've got a few questions if anybody's got a minute.
I'm trying to wrap my head around the threading situation in D. So far,
things seem to be working as expected, but I want to verify my solutions.
1) Are the following two snippets exa
On Tue, 2015-09-29 at 03:05 +, bitwise via Digitalmars-d-learn
wrote:
> On Monday, 28 September 2015 at 11:47:38 UTC, Russel Winder wrote:
> > I hadn't answered as I do not have answers to the questions you
> > ask. My reason: people should not be doing their codes using
> > these low-level s
On Monday, 28 September 2015 at 11:47:38 UTC, Russel Winder wrote:
I hadn't answered as I do not have answers to the questions you
ask. My reason: people should not be doing their codes using
these low-level shared memory techniques. Data parallel things
should be using the std.parallelism modu
x27;m trying to wrap my head around the threading situation in D.
> So far, things seem to be working as expected, but I want to
> verify my solutions.
>
> 1) Are the following two snippets exactly equivalent(not just in
> observable behaviour)?
> a)
>
> Mutex mut
Sorry I don't know the answers but these questions are
interesting so BUMP ;)
On Friday, 25 September 2015 at 15:19:27 UTC, bitwise wrote:
1) Are the following two snippets exactly equivalent(not just
in observable behaviour)?
a)
Mutex mut;
mut.lock();
scope(exit) mut.unlock();
b)
Mutex mu
Pretty please? :)
Hey, I've got a few questions if anybody's got a minute.
I'm trying to wrap my head around the threading situation in D.
So far, things seem to be working as expected, but I want to
verify my solutions.
1) Are the following two snippets exactly equivalent(not just in
obser
On 03/16/2015 12:04 PM, Suliman wrote:
Ali, please add text above to your book!
Will do. Please email me your full name at acehr...@yahoo.com so that I
can add it to the Acknowledgments section.
Thank you,
Ali
Ali, please add text above to your book!
On 03/16/2015 11:28 AM, Suliman wrote:
> difference between:
> auto theTask = task(&someFunction);
> and:
> auto theTask = task!anOperation();
tl;dr - Prefer task!anOperation() unless you can't. :)
task() is flexible enough to take what to execute either as a function
(or delegate) pointer (ta
Ali, again big thanks for your book, without it I was not able
how to work with D.
But for me now absolutely clear what difference between:
auto theTask = task(&someFunction);
and:
auto theTask = task!anOperation();
On 03/15/2015 01:53 PM, Suliman wrote:
I have App that read config sections. If the section is true I want to
run it in new thread.
if (parseconfig.obsmpplots_load == "true")
{
auto obsmpplots = new ObsmpPlots(db);
auto theTask = task(&obsmpplots.getPlots);
t
UP
I have App that read config sections. If the section is true I
want to run it in new thread.
if (parseconfig.obsmpplots_load == "true")
{
auto obsmpplots = new ObsmpPlots(db);
auto theTask = task(&obsmpplots.getPlots);
theTask.execu
On 12/07/2014 03:12 PM, Michael wrote:
now to figure out how to use them in the general case.
This is great.. Thank you. I'm looking forward to being able to try the
finished result.
My build servers are broken at the moment, but I think I have this
fixed, on linux at least.
On Monday, 8 December 2014 at 01:17:16 UTC, Ellery Newcomer wrote:
On 12/07/2014 03:12 PM, Michael wrote:
On Saturday, 6 December 2014 at 00:40:49 UTC, Ellery Newcomer
wrote:
On 12/04/2014 10:55 PM, Ellery Newcomer wrote:
I guess tomorrow I can try messing around with
thread_attachThis, as th
On 12/07/2014 03:12 PM, Michael wrote:
On Saturday, 6 December 2014 at 00:40:49 UTC, Ellery Newcomer wrote:
On 12/04/2014 10:55 PM, Ellery Newcomer wrote:
I guess tomorrow I can try messing around with thread_attachThis, as the
fullcollect happening in #2 might be screwing with python data. Bu
On Saturday, 6 December 2014 at 00:40:49 UTC, Ellery Newcomer
wrote:
On 12/04/2014 10:55 PM, Ellery Newcomer wrote:
I guess tomorrow I can try messing around with
thread_attachThis, as the
fullcollect happening in #2 might be screwing with python
data. But you
aren't really passing anything fr
On 12/04/2014 10:55 PM, Ellery Newcomer wrote:
I guess tomorrow I can try messing around with thread_attachThis, as the
fullcollect happening in #2 might be screwing with python data. But you
aren't really passing anything from python to d or vice versa, so I'm
not sure why the gc would need to
On 12/04/2014 02:11 PM, Michael wrote:
On Thursday, 4 December 2014 at 03:22:05 UTC, Ellery Newcomer wrote:
dustmite?
Not sure what went wrong with dustmite, but every time I tried it it
just started deleting all the files in the directory and setup.py would
give errors. I manually deleted a
On Thu, Dec 04, 2014 at 10:11:53PM +, Michael via Digitalmars-d-learn wrote:
> On Thursday, 4 December 2014 at 03:22:05 UTC, Ellery Newcomer wrote:
> >
> >dustmite?
>
> Not sure what went wrong with dustmite, but every time I tried it it
> just started deleting all the files in the directory a
On Thursday, 4 December 2014 at 03:22:05 UTC, Ellery Newcomer
wrote:
dustmite?
Not sure what went wrong with dustmite, but every time I tried it
it just started deleting all the files in the directory and
setup.py would give errors. I manually deleted a reasonable chunk
of the code and I'm
On 12/03/2014 06:56 PM, Michael wrote:
On Thursday, 4 December 2014 at 02:31:51 UTC, Ellery Newcomer wrote:
okay. that's not too surprising.
If you can get me a minimal example, I'd be happy to have a look since
pyd should probably support this case.
Cool. Unfortunately most of the times I'v
On Thursday, 4 December 2014 at 02:31:51 UTC, Ellery Newcomer
wrote:
okay. that's not too surprising.
If you can get me a minimal example, I'd be happy to have a
look since pyd should probably support this case.
Cool. Unfortunately most of the times I've attempted to reduce
this down it alw
On 12/03/2014 04:43 PM, Michael wrote:
On Wednesday, 3 December 2014 at 21:35:48 UTC, ketmar via
Digitalmars-d-learn wrote:
ah, dsource strikes back! that vile site keep biting us again and
again. let's hope that new admins will kill it for good.
Yeah. I've got the new PyD and it compiles and
On Wednesday, 3 December 2014 at 21:35:48 UTC, ketmar via
Digitalmars-d-learn wrote:
ah, dsource strikes back! that vile site keep biting us again
and
again. let's hope that new admins will kill it for good.
Yeah. I've got the new PyD and it compiles and does everything I
want much nicer, but
On Wed, 03 Dec 2014 20:41:46 +
Michael via Digitalmars-d-learn
wrote:
> On Wednesday, 3 December 2014 at 06:11:56 UTC, Ellery Newcomer
> wrote:
> > are you looking at this pyd:
> > https://bitbucket.org/ariovistus/pyd
>
> I'm looking at this one, which is what came up when googling
> "pyt
On Wednesday, 3 December 2014 at 06:30:07 UTC, Russel Winder via
Digitalmars-d-learn wrote:
As far as I can tell PyD is still active, but in a non-funded
FOSS way,
i.e. work happens as and when volunteers put time and effort
in. I
haven't tried PyD recently but it worked fine last time I did.
On Wednesday, 3 December 2014 at 06:11:56 UTC, Ellery Newcomer
wrote:
are you looking at this pyd:
https://bitbucket.org/ariovistus/pyd
I'm looking at this one, which is what came up when googling
"python to D"
http://pyd.dsource.org/
On Wed, 2014-12-03 at 01:07 +, Michael via Digitalmars-d-learn
wrote:
> Hi. I'm new here and this is my first post. I'm not sure this is
> the right subforum for it, but wasn't sure where else to put it
> either.
>
> I've written a library to talk to some external hardware using a
> socket.
On 12/02/2014 05:07 PM, Michael wrote:
Hi. I'm new here and this is my first post. I'm not sure this is the
right subforum for it, but wasn't sure where else to put it either.
I've written a library to talk to some external hardware using a socket.
It uses the std.concurrency threads to send mes
On Wed, 03 Dec 2014 01:07:42 +
Michael via Digitalmars-d-learn
wrote:
btw, Adam Ruppe's "D Cookbook" has a chapter which describes how to
call D library from C code. don't remember if it describes threading,
though.
signature.asc
Description: PGP signature
On Wed, 03 Dec 2014 01:07:42 +
Michael via Digitalmars-d-learn
wrote:
all in all, you'd better not mixing D code with "alien" mulththreaded
code and not using .a/.so libraries written in D in another language
until you are familiar with D runtime and GC. those mixes are very
fragile.
signat
On Wed, 03 Dec 2014 02:52:27 +
Michael via Digitalmars-d-learn
wrote:
by "using from C code" i mean that your main program is not written in
D, it has no D `main()` and so on. i.e. you wrote, for example, some
.a library in D and now you want to use that library in C code.
signature.asc
Des
On Wed, 03 Dec 2014 02:52:27 +
Michael via Digitalmars-d-learn
wrote:
> Okay. Well I am already not passing any D-allocated data. I'm
> specifically creating variables/arrays on the C-stack, and then
> passing the pointer of that to D and overwriting the data of the
> C-stack pointer for a
On Wednesday, 3 December 2014 at 02:41:11 UTC, ketmar via
Digitalmars-d-learn wrote:
On Wed, 03 Dec 2014 02:21:45 +
Michael via Digitalmars-d-learn
wrote:
Thanks for this. Its definitely a step in the right direction.
Would you mind explaining a bit more about the problem here,
if you c
On Wed, 03 Dec 2014 02:21:45 +
Michael via Digitalmars-d-learn
wrote:
> Thanks for this. Its definitely a step in the right direction.
> Would you mind explaining a bit more about the problem here, if
> you can? I don't fully understand why the garbage collector needs
> to know about the t
Thanks for this. Its definitely a step in the right direction.
Would you mind explaining a bit more about the problem here, if
you can? I don't fully understand why the garbage collector needs
to know about the threads, and if so for how long does it need to
know? If I put in
"thread_attachThi
On Wed, 03 Dec 2014 01:07:42 +
Michael via Digitalmars-d-learn
wrote:
> I'm fairly sure I have tackled both of these issues, but it still
> seems like Python threads and D threads don't mix well. When
> running the same functions from D, I am able to get no errors,
> but when run from Pyth
Hi. I'm new here and this is my first post. I'm not sure this is
the right subforum for it, but wasn't sure where else to put it
either.
I've written a library to talk to some external hardware using a
socket. It uses the std.concurrency threads to send messages
between the main D-object for
? Why "only" the n arrays, I thought those are
all?
> if I "duplicate"
> them(effectively write once read many) does that make things
> simpler and allow threading to be used more efficiently?
>
> Basically, instead of having to worry about threads waiting
I have to process n arrays in some partial order. Instead of all
working only on the n arrays and reusing them, if I "duplicate"
them(effectively write once read many) does that make things
simpler and allow threading to be used more efficiently?
Basically, instead of having to w
On Wednesday, 23 October 2013 at 12:41:58 UTC, Bauss wrote:
Thanks. It worked! :)
Connections is in thread local storage by default. If you want it
to be global across threads, you have to mark it shared or
__gshared.
On Wednesday, 23 October 2013 at 12:20:32 UTC, Meta wrote:
On Wednesday, 23 October 2013 at 11:51:35 UTC, Bauss wrote:
Working on a 2nd simple webserver in D. However I am facing a
problem with some threading. I want the receiving of
connections to happen in a 2nd thread, but after adding the
On Wednesday, 23 October 2013 at 11:51:35 UTC, Bauss wrote:
Working on a 2nd simple webserver in D. However I am facing a
problem with some threading. I want the receiving of
connections to happen in a 2nd thread, but after adding the
connections to the collection it seems like the receive
Working on a 2nd simple webserver in D. However I am facing a
problem with some threading. I want the receiving of connections
to happen in a 2nd thread, but after adding the connections to
the collection it seems like the receive thread never loops
through them, as if no connections were ever
On Oct 30, 2012, at 11:06 AM, Alex Rønne Petersen wrote:
> On 30-10-2012 19:04, Sean Kelly wrote:
>>
>>
>> The semaphore implementation for OSX is not signal-safe. Originally,
>> druntime used the signal approach on OSX and had deadlock issues in the
>> signal handler (OSX semaphores wrap a
1 - 100 of 141 matches
Mail list logo
