On Tuesday, 21 September 2021 at 09:37:30 UTC, Abby wrote:
Hi there,
I'm new in dlang I specially like betterC. I was hoping that d
fibers would be implemented in without using classes, but there
are not.
On windows you can use the fiber api
https://docs.microsoft.com/en-us/windows/
On Tuesday, 21 September 2021 at 09:37:30 UTC, Abby wrote:
Hi there,
I'm new in dlang I specially like betterC. I was hoping that d
fibers would be implemented in without using classes, but there
are not. Is there another way how to use async/await in dlang
better c?
Thank you for your
On Sunday, 26 September 2021 at 09:48:58 UTC, SealabJaster wrote:
...
I feel I didn't make it clear enough that extracting the code
would be way too much effort than its worth, especially since I'm
not even sure it runs on Linux. So I really wouldn't suggest
going down that route.
On Tuesday, 21 September 2021 at 09:37:30 UTC, Abby wrote:
...
I'm not aware of any -betterC package specifically for coroutines.
I have some work done in this regard, but sadly the library
itself isn't really usable at all so if you want to put in the
effort you'd have to probably extract t
On Tuesday, 21 September 2021 at 09:37:30 UTC, Abby wrote:
Hi there,
I'm new in dlang I specially like betterC. I was hoping that d
fibers would be implemented in without using classes, but there
are not. Is there another way how to use async/await in dlang
better c?
Thank you for your
Hi there,
I'm new in dlang I specially like betterC. I was hoping that d
fibers would be implemented in without using classes, but there
are not. Is there another way how to use async/await in dlang
better c?
Thank you for your help
Abby
On Friday, 9 April 2021 at 18:37:43 UTC, Jacob Carlborg wrote:
On 2021-04-09 11:00, rashir wrote:
Goodmorning everyone,
I'm trying to understand both Kqueue and Fiber's operation on
Mac. Why don't I get the correct data as long as I read from
the socket?
It seems to be reading too early, but K
On 2021-04-09 11:00, rashir wrote:
Goodmorning everyone,
I'm trying to understand both Kqueue and Fiber's operation on Mac. Why
don't I get the correct data as long as I read from the socket?
It seems to be reading too early, but Kquue tells me that the socket is
readable.
```D
const
On Friday, 9 April 2021 at 09:49:24 UTC, Arjan wrote:
On Friday, 9 April 2021 at 09:00:17 UTC, rashir wrote:
Goodmorning everyone,
I'm trying to understand both Kqueue and Fiber's operation on
Mac. Why don't I get the correct data as long as I read from
the socket?
It seems to be reading too e
On Friday, 9 April 2021 at 09:00:17 UTC, rashir wrote:
Goodmorning everyone,
I'm trying to understand both Kqueue and Fiber's operation on
Mac. Why don't I get the correct data as long as I read from
the socket?
It seems to be reading too early, but Kquue tells me that the
socket is readable.
On Sunday, 27 September 2020 at 16:39:45 UTC, Ali Çehreli wrote:
On 9/27/20 6:33 AM, Ferhat Kurtulmuş wrote:
> [...]
Kurtulmuş wrote:
>> [...]
wrote:
> [...]
processing
> [...]
How many flame threads do you need? I thought one image
processor and one flame thrower, no? Even if you hav
On 9/27/20 6:33 AM, Ferhat Kurtulmuş wrote:
> On Sunday, 27 September 2020 at 12:05:13 UTC, Ferhat Kurtulmuş wrote:
>> On Sunday, 27 September 2020 at 10:40:25 UTC, Ali Çehreli wrote:
>>> On 9/27/20 3:06 AM, Ferhat Kurtulmuş wrote:
>
> Oh, It will work fine if I imitate my time-consuming image pr
On Sunday, 27 September 2020 at 12:05:13 UTC, Ferhat Kurtulmuş
wrote:
On Sunday, 27 September 2020 at 10:40:25 UTC, Ali Çehreli wrote:
On 9/27/20 3:06 AM, Ferhat Kurtulmuş wrote:
Oh, It will work fine if I imitate my time-consuming image
processing like this.
I think it is Ok now.
import st
On Sunday, 27 September 2020 at 10:40:25 UTC, Ali Çehreli wrote:
On 9/27/20 3:06 AM, Ferhat Kurtulmuş wrote:
> __gshared DList!Entry queue;
> __gshared bool shouldRun = true;
Have you considered passing messages with
std.concurrency.send() and std.concurrency.receive() and
friends? You wouldn
On Sunday, 27 September 2020 at 10:52:58 UTC, Ferhat Kurtulmuş
wrote:
On Sunday, 27 September 2020 at 10:40:25 UTC, Ali Çehreli wrote:
[...]
[...]
I remember that your book covers passing messages with send().
Probably I will rewrite it using that mechanism, you are right,
I noticed that
On Sunday, 27 September 2020 at 10:40:25 UTC, Ali Çehreli wrote:
On 9/27/20 3:06 AM, Ferhat Kurtulmuş wrote:
Have you considered passing messages with
std.concurrency.send() and std.concurrency.receive() and
friends? You wouldn't need 'queue' because all of your threads
already have mail box
On 9/27/20 3:06 AM, Ferhat Kurtulmuş wrote:
> __gshared DList!Entry queue;
> __gshared bool shouldRun = true;
Have you considered passing messages with std.concurrency.send() and
std.concurrency.receive() and friends? You wouldn't need 'queue' because
all of your threads already have mail boxe
On Friday, 25 September 2020 at 13:37:09 UTC, Steven
Schveighoffer wrote:
Given the rate and the number of concurrent tasks, I'd say
threads.
-Steve
Here is my testable and minimal code using 1 extra thread. Thank
you all!
import core.thread;
import std.stdio;
import std.concurrency;
im
On 9/25/20 9:16 AM, Ferhat Kurtulmuş wrote:
On Friday, 25 September 2020 at 13:08:16 UTC, Sebastiaan Koppe wrote:
On Friday, 25 September 2020 at 11:58:53 UTC, Ferhat Kurtulmuş wrote:
[...]
No need for fibers per se.
You can run 2 threads. One that produces {time: now + 1500.msecs,
value
On Friday, 25 September 2020 at 13:13:50 UTC, Sebastiaan Koppe
wrote:
On Friday, 25 September 2020 at 13:08:16 UTC, Sebastiaan Koppe
wrote:
On Friday, 25 September 2020 at 11:58:53 UTC, Ferhat Kurtulmuş
How can I implement schedulePWMSignalToValve(pwmval,
afterNmilliseconds ) using fibers
On Friday, 25 September 2020 at 13:08:16 UTC, Sebastiaan Koppe
wrote:
On Friday, 25 September 2020 at 11:58:53 UTC, Ferhat Kurtulmuş
wrote:
[...]
No need for fibers per se.
You can run 2 threads. One that produces {time: now +
1500.msecs, value: getFlameIntensityViaImageProcessing} objects
On Friday, 25 September 2020 at 13:08:16 UTC, Sebastiaan Koppe
wrote:
On Friday, 25 September 2020 at 11:58:53 UTC, Ferhat Kurtulmuş
How can I implement schedulePWMSignalToValve(pwmval,
afterNmilliseconds ) using fibers?
No need for fibers per se.
Can also use https://code.dlang.org
// a possible solution:
// enum afterNmilliseconds = 1500;
// schedulePWMSignalToValve(pwmval, afterNmilliseconds
);
...
}
...
}
How can I implement schedulePWMSignalToValve(pwmval,
afterNmilliseconds ) using fibers?
Thanks in advance.
No need for fibers per
On Friday, 25 September 2020 at 12:43:41 UTC, Imperatorn wrote:
On Friday, 25 September 2020 at 11:58:53 UTC, Ferhat Kurtulmuş
wrote:
[...]
A naive implementation would be to store 1500 ms worth of data
with the pwm values, like a buffer. I guess memory is not a
problem if you're using a RP3
On Friday, 25 September 2020 at 11:58:53 UTC, Ferhat Kurtulmuş
wrote:
Hi,
I have a problem to solve that may be solved using fibers. I
have no previous experience with fibers. We are working on a
variable-rate weeder. A camera is installed in front of a
tractor. A flame weeder is connected
Hi,
I have a problem to solve that may be solved using fibers. I have
no previous experience with fibers. We are working on a
variable-rate weeder. A camera is installed in front of a
tractor. A flame weeder is connected to the behind of a tractor.
Doing image processing (on RP3), we
On Friday, 22 May 2020 at 06:10:38 UTC, Atwork wrote:
Is it possible to mix fibers with sockets from phobos?
If so, how would I do it?
Like just a simple example of async sockets using fibers in D.
I will say that I'd prefer to not use any packages ex. vibe.d
Yes you can mix std so
Is it possible to mix fibers with sockets from phobos?
If so, how would I do it?
Like just a simple example of async sockets using fibers in D.
I will say that I'd prefer to not use any packages ex. vibe.d
On Sunday, 21 April 2019 at 16:20:51 UTC, WebFreak001 wrote:
I'm trying to GC profile serve-d which uses a lot of fibers
potentially also across some threads and some threads doing
some dedicated work, however -profile=gc doesn't seem to work
properly. It logs `shared static this`
I'm trying to GC profile serve-d which uses a lot of fibers
potentially also across some threads and some threads doing some
dedicated work, however -profile=gc doesn't seem to work
properly. It logs `shared static this` calls and some methods,
however none of the actual stuff is in
I'm porting LZHAM to D, and the original used some very unusual
approach for coroutines:
- the whole thing is running inside of a single switch-case
block created by C++ macros
- the function saves some local values
- a macro sets the state variable to the current line number,
returns the st
On 4/24/18 10:12 PM, bitwise wrote:
On Friday, 20 April 2018 at 18:58:36 UTC, Byron Moxie wrote:
[...]
In WIN32 it looks like its leaking memory
Unless there is something I'm misunderstanding, it seems that Fibers
that were not run to completion won't unroll their stack, which w
On Friday, 20 April 2018 at 18:58:36 UTC, Byron Moxie wrote:
[...]
In WIN32 it looks like its leaking memory
Unless there is something I'm misunderstanding, it seems that
Fibers that were not run to completion won't unroll their stack,
which would mean that some destructors w
On 4/24/18 4:30 PM, Steven Schveighoffer wrote:
I'll file an issue. We may not be able to solve the problem, but it's
something we should try and solve.
Seems there's already a similar issue in there:
https://issues.dlang.org/show_bug.cgi?id=3523
-Steve
wrote:
On Tuesday, 24 April 2018 at 00:46:39 UTC, Byron Heads wrote:
[...]
This is not a fiber issue but a more memory management issue. Your
run out of address space on win32, the GC will not always collect
all those 9 fibers that you allocate in that loop. As an
exercise replace `auto` with
00:46:39 UTC, Byron Heads
wrote:
[...]
This is not a fiber issue but a more memory management
issue. Your run out of address space on win32, the GC will
not always collect all those 9 fibers that you allocate
in that loop. As an exercise replace `auto` with `scope`
like `scope foo = new
On 25/04/2018 5:13 AM, Steven Schveighoffer wrote:
On 4/24/18 12:49 PM, kinke wrote:
On Tuesday, 24 April 2018 at 16:22:04 UTC, Steven Schveighoffer wrote:
On 4/24/18 10:31 AM, Byron Heads wrote:
I will start ignoring win32 when win64 doesn't require dealing with
visual studio installs.
Also
On 4/24/18 12:49 PM, kinke wrote:
On Tuesday, 24 April 2018 at 16:22:04 UTC, Steven Schveighoffer wrote:
On 4/24/18 10:31 AM, Byron Heads wrote:
I will start ignoring win32 when win64 doesn't require dealing with
visual studio installs.
Also I have a feeling a client will ask for it.
Unfortu
On Tuesday, 24 April 2018 at 16:22:04 UTC, Steven Schveighoffer
wrote:
On 4/24/18 10:31 AM, Byron Heads wrote:
I will start ignoring win32 when win64 doesn't require dealing
with visual studio installs.
Also I have a feeling a client will ask for it.
Unfortunately I don't think the VS license
On 4/24/18 10:31 AM, Byron Heads wrote:
On Tuesday, 24 April 2018 at 13:36:48 UTC, Steven Schveighoffer wrote:
This is not the case of executing 100,000 concurrent fibers, but
executing 100,000 *sequential* fibers. It should work just fine.
Correct, in a normal run of my system there maybe
a more memory management issue. Your
run out of address space on win32, the GC will not always collect
all those 9 fibers that you allocate in that loop. As an
exercise replace `auto` with `scope` like `scope foo = new Foo();`
in that loop - you should see different results.
This shouldn&#
On Tuesday, 24 April 2018 at 13:36:48 UTC, Steven Schveighoffer
wrote:
On 4/24/18 5:11 AM, bauss wrote:
On Tuesday, 24 April 2018 at 07:58:01 UTC, Radu wrote:
On Tuesday, 24 April 2018 at 00:46:39 UTC, Byron Heads wrote:
Fibers on Win32 have a memory leak for sure:
import core.thread
.
Your run out of address space on win32, the GC will not
always collect all those 9 fibers that you allocate in
that loop. As an exercise replace `auto` with `scope` like
`scope foo = new Foo();` in that loop - you should see
different results.
This shouldn't be a requirement, the 32-b
On 4/24/18 5:11 AM, bauss wrote:
On Tuesday, 24 April 2018 at 07:58:01 UTC, Radu wrote:
On Tuesday, 24 April 2018 at 00:46:39 UTC, Byron Heads wrote:
Fibers on Win32 have a memory leak for sure:
import core.thread : Fiber;
void main() {
foreach(ulong i; 0..99_999) {
auto foo
afe in all
places.
FWIW, I'm using vibe.d on Linux 64 bit with no problems (and
I've NEVER heard of atomicLoad and atomicStore not working
on any arch).
-Steve
I had move the data I wanted to sync with atomicLoad/Store
into a shared struct and pass a pointer to this struct to th
64 bit with no problems (and
I've NEVER heard of atomicLoad and atomicStore not working on
any arch).
-Steve
I had move the data I wanted to sync with atomicLoad/Store
into a shared struct and pass a pointer to this struct to the
other fibers. Not sure if this was an issue with TLS
On 4/23/18 8:46 PM, Byron Heads wrote:
Fibers on Win32 have a memory leak for sure:
import core.thread : Fiber;
void main() {
foreach(ulong i; 0..99_999) {
auto foo = new Foo();
foo.call();
foo.call();
}
}
It sure looks like this should be fine, the GC
Load and atomicStore not working on
any arch).
-Steve
I had move the data I wanted to sync with atomicLoad/Store into
a shared struct and pass a pointer to this struct to the other
fibers. Not sure if this was an issue with TLS messing with
class object I was passing around.
Fibers on
had move the data I wanted to sync with atomicLoad/Store into a
shared struct and pass a pointer to this struct to the other
fibers. Not sure if this was an issue with TLS messing with class
object I was passing around.
On 4/20/18 2:58 PM, Byron Moxie wrote:
I am working on an application that makes heavy use of Fibers pools that
are processed by a thread pool.
In WIN32 it looks like its leaking memory then it segfaults (I am
guessing its an OOM).
I am also trying to use Semaphores and/or Conditions on
On 21/04/2018 6:58 AM, Byron Moxie wrote:
I am working on an application that makes heavy use of Fibers pools that
are processed by a thread pool.
In WIN32 it looks like its leaking memory then it segfaults (I am
guessing its an OOM).
I am also trying to use Semaphores and/or Conditions on
I am working on an application that makes heavy use of Fibers
pools that are processed by a thread pool.
In WIN32 it looks like its leaking memory then it segfaults (I am
guessing its an OOM).
I am also trying to use Semaphores and/or Conditions on shared
data between fibers, which results
On Tuesday, 25 October 2016 at 21:23:21 UTC, Arun Chandrasekaran
wrote:
I am looking for a RESTful framework in D, which can interact
with an existing backend processes (C++) via ZeroMQ and shared
memory. I thought vibe.d might be a viable option. But I
discussed with someone on Freenode #d and
I am looking for a RESTful framework in D, which can interact
with an existing backend processes (C++) via ZeroMQ and shared
memory. I thought vibe.d might be a viable option. But I
discussed with someone on Freenode #d and found that vibe.d
doesn't support explicit threading [1].
Can someone
On Monday, 13 June 2016 at 00:57:11 UTC, Alex Parrill wrote:
This is misleading. Any sort of cooperative system needs
synchronization when two or more tasks try to access the same
data, whether those "tasks" are OS threads, fibers, different
machines on a network, etc.
That is t
synchronization as if you were using threads.
Vibe.d framework share the same fibers between threads?
Or each thread have his own fibers?
I was trying this(shared fibers) but it didnt work.
D fibers don't (actually, can't) move between threads. Vibe.d uses
regular D fibers, so it&#x
.
Vibe.d framework share the same fibers between threads?
Or each thread have his own fibers?
I was trying this(shared fibers) but it didnt work.
On Sunday, 12 June 2016 at 08:38:03 UTC, chmike wrote:
Fibers don't need synchronization to access shared data. This
removes the overhead of synchronization and simplifies
"multitheaded" programming greatly.
This is misleading. Any sort of cooperative system needs
synchronizat
On Sunday, 12 June 2016 at 05:11:57 UTC, Ali Çehreli wrote:
For convenience, here's the link:
http://www.ustream.tv/recorded/86352137/highlight/699197
unfortunately iPads are not supported to view the video. :(
I see two major benefits of fibers overs threads.
Fibers don&#
On 06/11/2016 07:58 PM, Era Scarecrow wrote:
> recent DConf 2016 which sorta covers this
For convenience, here's the link:
http://www.ustream.tv/recorded/86352137/highlight/699197
However although I'm very biased :), I still like the following fiber
explanation that emphasizes function cal
On Sunday, 12 June 2016 at 02:43:40 UTC, Patric Dexheimer wrote:
I learned about Fibers on D, and now I´m starting to read about
it (Threads/Fibers/Coroutines) etc. But when I try to make
something usefull with it I just fail to see the real advantage
over a normal structured programming
I learned about Fibers on D, and now i´m starting to read about
it (Threads/Fibers/Coroutines) etc.
But when i try to make something usefull with it i just fail to
see the real advantage over a normal structured programming
without it.
Can someone show some code with usefull/unique
On Thursday, 9 June 2016 at 16:13:21 UTC, Jonathan Marler wrote:
I don't see that documentation anywhere on that page.
https://issues.dlang.org/show_bug.cgi?id=16148
7;t
found too
much on how fibers are implemented. How does yield return
execution
to the caller but then resume execution in the same place on
the next
call? Also some information on how the fiber call stack
works would
be nice. I'm assuming it allocates the stack on the GC
heap. If
On 6/9/16 2:15 PM, Jonathan Marler wrote:
On Thursday, 9 June 2016 at 05:07:33 UTC, Nikolay wrote:
On Thursday, 9 June 2016 at 04:57:30 UTC, Jonathan Marler wrote:
I've googled and searched through the forums but haven't found too
much on how fibers are implemented. How does yi
On Thursday, 9 June 2016 at 05:07:33 UTC, Nikolay wrote:
On Thursday, 9 June 2016 at 04:57:30 UTC, Jonathan Marler wrote:
I've googled and searched through the forums but haven't found
too much on how fibers are implemented. How does yield return
execution to the caller but t
On Thursday, 9 June 2016 at 04:57:30 UTC, Jonathan Marler wrote:
I've googled and searched through the forums but haven't found
too much on how fibers are implemented. How does yield return
execution to the caller but then resume execution in the same
place on the next call?
I've googled and searched through the forums but haven't found
too much on how fibers are implemented. How does yield return
execution to the caller but then resume execution in the same
place on the next call? Also some information on how the fiber
call stack works would be
On Friday, 18 September 2015 at 07:58:10 UTC, ddos wrote:
hello!
yesterday i got curious about how fibers work, and if the can
be used as a replacement in network programming. so i started
hacking a small example together, which is hopefully useful to
other D beginners too :)
http
hello!
yesterday i got curious about how fibers work, and if the can be
used as a replacement in network programming. so i started
hacking a small example together, which is hopefully useful to
other D beginners too :)
http://pastebin.com/Xg4GJbKE
On Monday, 27 July 2015 at 18:30:06 UTC, Gary Willoughby wrote:
Where is the discussion?
This must be it
http://forum.dlang.org/thread/pflkijjjuyyhextxv...@forum.dlang.org
I'm interested in the same subject right now, and was wondering
about the same question you asked.
On Monday, 27 July 2015 at 08:00:10 UTC, Marc Schütz wrote:
On Sunday, 26 July 2015 at 18:07:51 UTC, Gary Willoughby wrote:
In the description for Fiber in std.thread is the following[1]:
"Please note that there is no requirement that a fiber be
bound to one specific thread. Rather, f
On Sunday, 26 July 2015 at 18:07:51 UTC, Gary Willoughby wrote:
In the description for Fiber in std.thread is the following[1]:
"Please note that there is no requirement that a fiber be bound
to one specific thread. Rather, fibers may be freely passed
between threads so long as they ar
On Sunday, 26 July 2015 at 19:51:08 UTC, Ali Çehreli wrote:
On 07/26/2015 11:07 AM, Gary Willoughby wrote:> In the
Thanks for the example. I'll study it.
On 07/26/2015 11:07 AM, Gary Willoughby wrote:> In the description for
Fiber in std.thread is the following[1]:
>
> "Please note that there is no requirement that a fiber be bound to one
> specific thread. Rather, fibers may be freely passed between threads so
> long as th
In the description for Fiber in std.thread is the following[1]:
"Please note that there is no requirement that a fiber be bound
to one specific thread. Rather, fibers may be freely passed
between threads so long as they are not currently executing."
How would this be accomplish
On 2015-06-16 18:36:09 +, Rob T said:
FYI:
https://issues.dlang.org/show_bug.cgi?id=11686
https://issues.dlang.org/show_bug.cgi?id=11687
Thanks. We are currently experimenting to see how want to use the
threads and what code to refactor. If we are going to bite the bullet I
keep this in
On Sunday, 14 June 2015 at 15:54:30 UTC, Etienne Cimon wrote:
On 2015-06-14 08:35, Robert M. Münch wrote:
Hi, just to x-check if I have the correct understanding:
fibers = look parallel, are sequential => use 1 CPU
core
threads = look parallel, are parallel => use severa
On 2015-06-14 15:54:30 +, Etienne Cimon said:
Yes, however nothing really guarantees multi-threading = multi-core.
The kernel reserves the right and will most likely do everything
possible to keep your process core-local to use caching efficiently.
Hi, sure. It's more about raising the ch
On Sunday, 14 June 2015 at 12:35:44 UTC, Robert M. Münch wrote:
Hi, just to x-check if I have the correct understanding:
fibers = look parallel, are sequential => use 1 CPU core
threads = look parallel, are parallel => use several CPU cores
Is that right?
Fib
On 2015-06-14 08:35, Robert M. Münch wrote:
Hi, just to x-check if I have the correct understanding:
fibers = look parallel, are sequential => use 1 CPU core
threads = look parallel, are parallel => use several CPU cores
Is that right?
Yes, however nothing really guar
On Sunday, 14 June 2015 at 12:35:44 UTC, Robert M. Münch wrote:
Hi, just to x-check if I have the correct understanding:
fibers = look parallel, are sequential => use 1 CPU core
threads = look parallel, are parallel => use several CPU cores
Is that right?
Pretty much.
Hi, just to x-check if I have the correct understanding:
fibers = look parallel, are sequential => use 1 CPU core
threads = look parallel, are parallel => use several CPU cores
Is that right?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
On Friday, 24 April 2015 at 12:38:39 UTC, Jens Bauer wrote:
On Friday, 24 April 2015 at 09:15:21 UTC, Chris wrote:
I was more thinking of the audio thread. But the audio is
probably better off in a separate thread.
I think you could do this too.
In fact, this is very similar to how the audio
On Friday, 24 April 2015 at 09:15:21 UTC, Chris wrote:
I was more thinking of the audio thread. But the audio is
probably better off in a separate thread.
I think you could do this too.
In fact, this is very similar to how the audio from a MOD file is
decoded.
(I only mentioned an interrupt,
moment I'm using threads to implement a speech
synthesizer. It waits for input, synthesizes it, and then
"speaks" in a separate thread. If new input comes, the
speaking thread is stopped. I wonder, if fibers would be a
viable alternative to threads (after all audio playback was
m
r. It waits for input, synthesizes it, and then
"speaks" in a separate thread. If new input comes, the speaking
thread is stopped. I wonder, if fibers would be a viable
alternative to threads (after all audio playback was mentioned
in the list above).
I'll try and give you s
.
This is great information. I didn't know anything about Fibers
before today.
Since I started looking at D, I've seen many new and innovative
ways of programming.
Fibers are definitely also beneficial for microcontrollers.
I can think of a few things that would make good use of Fibers:
1:
On Thursday, 23 April 2015 at 14:22:01 UTC, Ali Çehreli wrote:
On 04/23/2015 06:56 AM, ref2401 wrote:
http://ddili.org/ders/d.en/fibers.html
I appreciate any feedback before the book is finally printed
sometime before DConf.
This is great information. I didn't know anything about F
Awesome!
On 04/23/2015 06:56 AM, ref2401 wrote:
I'm intrested in fibers and async io.
Could anyone suggest articles, books or tutorials about the subject?
Thank you
I am working on adding a Fibers chapter to my book. Although it is still
a draft and not linked from any other page, I've made
I'm intrested in fibers and async io.
Could anyone suggest articles, books or tutorials about the
subject?
Thank you
On Saturday, 13 December 2014 at 12:26:49 UTC, zeljkog wrote:
On 13.12.14 13:01, zeljkog wrote:
void main() {
auto tt = Tree(5, [Tree(7,[Tree(11), Tree(4)]), Tree(10)]);
auto tr1 = TreeRange(tt);
foreach(v; tr1){
writef("%2d, ", v);
}
writeln();
for(auto r = TreeRange(tt); !r.em
On 13.12.14 13:01, zeljkog wrote:
void main() {
auto tt = Tree(5, [Tree(7,[Tree(11), Tree(4)]), Tree(10)]);
auto tr1 = TreeRange(tt);
foreach(v; tr1){
writef("%2d, ", v);
}
writeln();
for(auto r = TreeRange(tt); !r.empty; r.popFront())
writef("%2d, ", r.front);
wri
When you assigning the worker in TreeRange, you create a delegate
that captures the current TreeRange or 'this'.
---
worker = new Fiber(&fiberFunc);
---
foreach is defined as
(http://dlang.org/statement.html#ForeachStatement):
---
for (auto __r = range; !__r.empty; __r.popFront())
{
import std.stdio, core.thread;
struct Tree{
int val;
Tree[] tree;
}
struct TreeRange{
Tree curtree;
bool empty;
Fiber worker;
this(Tree t){
worker = new Fiber(&fiberFunc);
curtree = t;
popFront();
}
void fiberFunc(){
Tree t = curtree;
Fiber.yield();
f
work.
Perhaps this example is oversimplified, but fibers won't help in
doing some operation at the exact same time. They will still run
sequentially, on a single CPU, as if no threads/fibers were used.
I don't think there is a way to perform an operation in a truly
atomic way on a di
On 9/17/14, 9:43 PM, Kagamin wrote:
fibs ~= new TestFiber(entry);
should just work without accounting for number of items
Kagamin/Flamencofantasy, thank you very much.
and
fibs.length = count;
fibs ~= new TestFiber(entry);
should just work without accounting for number of items
1 - 100 of 121 matches
Mail list logo
