Re: need help with long processing app that will allow user to cancel process.

From: Martin James (mjames_falcon_at_dial.pipex.com)
Date: 11/15/03 

Date: Sat, 15 Nov 2003 16:33:09 -0000

"> "then forget about it ". People just forget to do some important tasks.
> This is a root of evil.

<g> my 'roots of evil' are application.processMessages,
freeOnTerminate=false, onTerminate, TThread.waitfor. Not necessarily in
that order.

> In your philosophically, you do not understand that threads are used for
> lengthly tasks (blocking I/O and so on).

That's what I use them for. Database queries, IP servers & clients for all
the various protocols, logging, file processing, anywhere an oeration is
requied that will need an IO wait or heavy & extended CPU usage.

Calling *Free* does not take a lot
> of time to accomplish.

Maybee not, but it's avoidable. How would you want your thread stuff to
free?:

a) In the context of the main thread that has five windows to paint to keep
up. After a 500ms 'waitFor' dead zone. After a TidHTTP free.
b) Whenever there's free time for a low-priority thread?

If we look into core of memory manager, I'm sure that
> we'll see a synchronization point protecting managment of heap blocks.

Sure, else the MM would blow up. The memory CS is another good reason for
not creating & freeing threads during an app run unless it absoultly has to
happen.

 So,
> hypothetically having multiprocessor PC, you do not have any benefit.
> If you want more phylosophy. We had Gogol's (a famous Ukraine writer)
called
> "Taras Bulba" in out school program. The most dramatic moment of the book
is
> where a father killing his son is telling "I've born you, I'll kill you"
> (translation is mine). This allows for better control of objects'
lifetime.
> Philosophy of programming states that an object thould be disposed by
> creating object (there are some exceptions like Factories, of course).
> Finally, bad style of code warns. That this "simple example of Thread
> application" serves as a great reference of how we should not do. This
> includes avoiding FreeOnTerminate.

I've never read any of Gogol's work, but I sympathise & agree with the
general idea of "
Philosophy of programming states that an object thould be disposed by
creating object"

Even then, you state one exception to this guide - class/instance factories.
If an exception can be made for a mere function that returns an object, why
can an exception not be made for a detached thread that has its own stack,
OS descriptor structures, is independently scheduled & may not even run on
the same processor?

I have to say that, in the case of threads, the pretty design concept
illustrated by Gogol's works, (go on then - I'll Google for Gogol), can be
safely be ignored by the performance & ease-of-use of a thread that can die
by itself.

In general, I really don't want the creators to hang around waiting for,
say, a busy winsock to disconnect & close a socket connection in a worker
thread. Why sieze up the caller & wait when it can be avoided?

> >
> > There are cases where a thread holds some resource that is required
> > elsewhere before some other thread can proceed. That's about the only
> case
> > where I can see any justification for 'waitFor'. Even then, I prefer
> > posting off the resource rather than waitFor'ing it. These cases are
> anyway
> > very rare, (in my apps, anyway).
>
> THERE ARE CASES WHERE A THREAD REFERS A SHARED RESOURCE, ... THESE ARE
VERY
> RARE!!!

No need to shout!

> Where do you leave? Which programs do you write? Have you ever heard about
> resource locking and its purpose in multithreading?

> As I've said, you concept of threads is wrong. The simplest use of threads
> is the following. If you've ever looked into tutolials for beginners, you
> should know that the basic use of multiple threads is to create them, wait
> for they are complete and proceed.

No. If this was the case, threads would be a procedure call with an
annoyingly complex & pointless call mechanism. If I want to call a
procedure, why not just use the normal 'push the return address' mechanism?
It has an inherent 'wait until the procedure has completed' system built in.

99.9% of all household threads run for extended periods. Look at your task
manager. Most of the threads are in OS services & are there when I start
Windows & are still there weeks later. If I don't crash 2k, they'll still
be there next month.

The 'tutorials for beginners' that advocate creating threads & waiting for
them to complete are, err... 'not very good'. Unfortuanately, there are
Borland examples that imply that this is the 'proper & only way' to use
threads.

'TThread.waitFor' does not even have a timeout. Hopeless.

No need for any events, messages. WaitFor
> gives you the synchronization point after which you can proceed.

It's best to avoid the need for synchronizatin points at all. A synchro
point means that something has to wait, often avoidably.

 Posting
> messages and events is an advanced topic.

Not really. Producer/consumer queues & semaphores have been around since
the birth of multitasking OS.

 What the hell should one exchange
> any messages just to stop a thread?

To return any objects that the thread did not create & may have been passed
in, either as constructor parameters, in messages or some other
communication mechanism. Off-hand, I cannot remember one single case where
I've had to do this. Usually, it's 'myThread.die' and forget about it. The
thread can release all its own stuff when it gets a round tuit.

> Form.Destroy
> begin
> AThread.Terminate();
> AThread.WaitFor(); (* ie. stop doing anything at all, even though
there is probably lots to do *)
> AThread.Free();

> If Thread frees itself, you cannot be sure you don't get "illegal access
> violation" ecxption terminating it.

Even with threads that are terminated before app shutdown, ie. where an AV
may actually matter, it doesn't happen. Several posters have suggested
that it can, but it just doesn't happen.

Rgds,
Martin

Relevant Pages

  • OutOfMemoryException: major production problems
    ... On our production servers we receive the following events (in more detail ... * System.OutOfMemoryException: Exception of type System.OutOfMemoryException ... Failed to load resources from resource file ... The local computer may not have the necessary registry information or ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: logfile msg: get method and class names
    ... because the PostMessage queue is FIFO. ... believe "the best synchronization is no synchronization", which is to say that you should ... STL-compatible exception you throw, ... that people overuse it, but I digress;-)). ...
    (microsoft.public.vc.mfc)
  • Re: logfile msg: get method and class names
    ... actual logging code into a synchronized block. ... believe "the best synchronization is no synchronization", which is to say that you should ... STL-compatible exception you throw, ... that people overuse it, but I digress;-)). ...
    (microsoft.public.vc.mfc)
  • Re: whats the point in finally?
    ... throw new MyGenericException("Can parse xml", ... If you throw an exception from a destructor and the destructor is called due to an exception unwinding the stack then, IIRC, abort is called which by default calls terminate. ... Unfortunately "ownership" of the resource is moved into the decorator. ... In order to support such decorators, all resources can throw exceptions when being closed. ...
    (comp.lang.java.programmer)
  • Re: Completism
    ... > My collection of convertiana has many, many very common items and ... As a resource, a complete collection is obviously more valuable than ... convinces them it is VALUABLE.] ... Another exception could be when ...
    (rec.collecting.books)