Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #2279 > unrolled thread

long tasks

Back to article view | Back to comp.programming

Contents

  long tasks bob <bob@coolfone.comze.com> - 2012-10-02 07:36 -0700
    Re: long tasks Ian Collins <ian-news@hotmail.com> - 2012-10-03 09:07 +1300
    Re: long tasks Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-10-02 13:26 -0700

#2279 — long tasks

I've noticed that one of the things that makes real-world programming difficult is time-consuming tasks (or potentially time-consuming tasks).  Some examples are downloading a file & reading from a database (maybe).

Usually these are handled in the real-world by things like multi-threading and callbacks, which can quickly turn messy.  Are there other strategies that can maybe handle these things more simply?

One theoretical ideal approach is to just "make everything fast."  Of course, this is more theoretical than practical.

[toc] | [next] | [standalone]

#2282

On 10/03/12 03:36, bob wrote:

Please wrap your lines!

> I've noticed that one of the things that makes real-world programming difficult is time-consuming tasks (or potentially time-consuming tasks).  Some examples are downloading a file&  reading from a database (maybe).
>
> Usually these are handled in the real-world by things like multi-threading and callbacks, which can quickly turn messy.  Are there other strategies that can maybe handle these things more simply?

Sit and wait.  Alternatives such as threading only add value if there is 
useful work that can be done while the slow operation is in progress.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2283

On 10/2/12 7:36 AM, bob wrote:
> I've noticed that one of the things that makes real-world programming difficult is time-consuming tasks (or potentially time-consuming tasks).  Some examples are downloading a file & reading from a database (maybe).
Or rendering a video using ray-tracing.
>
> Usually these are handled in the real-world by things like multi-threading

It is often considered "polite" to run long tasks off of the GUI 
processing thread, so if that's what you mean by "multi-threading", then 
yes, that is common.

> and callbacks

Yes, this is the easiest approach, although there are more complex ones 
that can be used.

>, which can quickly turn messy.

I disagree.  Callbacks aren't that difficult, and if they "turn messy", 
then something else is wrong.

> Are there other strategies that can maybe handle these things more simply?

Well, you can sometimes get away from *either* callbacks or 
multi-threading, but usually you need at least one of those to have a 
progress indication. In GUI programming, you need both to have an 
efficient and responsive UI.

Anything can turn messy, and many people start creating multi-threaded 
programs without an understanding of how that works.  Multi-threaded 
programming isn't hard, but it isn't the same as single threaded 
programming.  Unfortunately, we're taught single-threaded programming, 
and then often extrapolate incorrectly what that means in a 
multi-threaded context.

> One theoretical ideal approach is to just "make everything fast."  Of course, this is more theoretical than practical.
This is not a good approach, because the faster you make something, the 
more of it the user wants you to do in one batch.

Also, fast is subjective.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web