On 22/09/15 08:48, Aaron Meriwether wrote:
On Sep 20, 2015, at 1:20 AM, Ray Satiro via curl-library
<[email protected]> wrote:
On 9/18/2015 6:47 AM, doa379 wrote:
On 18/09/15 01:22, Aaron Meriwether wrote:
On Sep 17, 2015, at 1:06 PM, doa379 <[email protected]> wrote:
I think my issue has resolved itself by putting in a delay to some of the
operations in the threads.
If you use delays to "fix" a bug in a threaded program, you are doing it wrong,
and the bug will almost certainly resurface later to bite you.
-Aaron
On 18/09/15 05:53, Ray Satiro via curl-library wrote:
That doesn't sound right. I think your solution is possibly covering up
a problem with the design of your program.
The program follows this example:
http://softpixel.com/~cwright/programming/threads/threads.c.php
The example has two threads and is using usleep like a yield to allow for a
task switch but I don't think he adequately explains that. The order in which
the output appears in your console is unpredictable, however it will usually
alternate.
"The output will be (mostly) alternating lines as the main() and threadFunc()
threads execute and pause. Without the usleep()'s they'll not switch because we aren't
doing anything that takes long enough to consume our whole time slice."
He is trying to show how a scheduler will run threads by multiplexing them in time
slices on a core. Scheduler says do some of this thread then time's up and
scheduler says do some of that thread and so on. But the whole time slice isn't
necessarily consumed and also both threads may be running at the same time in
parallel truly concurrent if they're running on different cores. They may
alternate because they're both calling printf and there is lock contention to
obtain ownership of stdout. In other words one thread has to wait to write if the
other is writing to the same. Also, usleep guarantees at a minimum suspension of n
microseconds if no signal, not maximum so it could be any amount of microseconds
>= n before a thread resumes.
I think we are treading outside the scope of this list now but how have you
followed the example in your program? My take so far is you have one thread
that is performing the transfer using libcurl and receiving a continuous stream
of records, and those records are then processed by other threads concurrently.
I don't understand why you would fork the libcurl thread; also there seem to be
some problems with forking and multi-threading. I am mostly in Windows so
someone experienced in forking multi-threaded apps would be better to explain
why you should or shouldn't do that.
Right, the softpixel page mentions several different thread-related concepts. The
"usleep" in the examples is not being used to reliably resolve a race
condition, but as a hack to give a higher probability that the example will exhibit
interesting behavior. That page also mentions the use of mutexes, which is the proper
path if you need reliable inter-thread resource-sharing. However, neither of the
multithreading examples given on that page actually make use of a mutex.
If you want to use curl in the background, writing to an in-memory buffer, and
to access that buffer from another thread, you will need to use a mutex to
ensure that the accesses from your two different threads do not conflict. I've
written a quick example to show how you can use a background worker thread and
a mutex in order to safely accomplish this:
https://gist.github.com/p120ph37/906fa4af65da7948d69b
-Aaron
Yes this is a correct way to do it. Ideally. Locking resources whilst
manipulating the respective variables in set order.
At the moment I have one thread running which is crudely updating data
from the internet into some variables. As the performance is limited by
network latency there's appears to be less of a reason to slow things
down in infinite loops using usleep() function say.
Thanks for your suggestion.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
