Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread Bomb proofing threads
Tue, Aug 25 2009 8:42 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

I know about isolating components (session, database, query, table) in threads and do that but now I want to bomb proof them for those instances when the app terminates before the thread which then tries to write to a table.

The reason this has risen is my email subsystem for a multi-user app. It downloads any web graphics for an email (if its not going into SPAM or SUSPICIOUS) and stores them locally. This can mean that the thread is still working away when the app is closed. Waiting for the thread to terminate could take quite a while so I want to just close the app.

If the thread is still running and then reaches a point where it wants to post the data to a table the engine will be shut down so I'm going to get errors.

What I want to do is

1) make sure the tables aren't damaged (corrupted)
2) preferably not let the user see there's been a problem

What do you lot do?

Roy Lambert
Tue, Aug 25 2009 9:03 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< The reason this has risen is my email subsystem for a multi-user app. It
downloads any web graphics for an email (if its not going into SPAM or
SUSPICIOUS) and stores them locally. This can mean that the thread is still
working away when the app is closed. Waiting for the thread to terminate
could take quite a while so I want to just close the app. >>

I wouldn't do what you're thinking about doing.  What you want is a way to
notify the thread that the application is closing, and then wait for the
thread to terminate normally.  Is there a way for your process to
occasionally check to see if the thread has been terminated
(TThread.Terminated=True) ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tue, Aug 25 2009 9:31 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

>I wouldn't do what you're thinking about doing. What you want is a way to
>notify the thread that the application is closing, and then wait for the
>thread to terminate normally. Is there a way for your process to
>occasionally check to see if the thread has been terminated
>(TThread.Terminated=True) ?

I would agree with you but for the downloading web graphics. One of my news feeds is Woodstock Wire, first there are the obligatory crap ads and secondly there are financial graphs. With redirection time included downloading a single graph can take 30 secs (BT upto 8Mb connection, on dial up I just wouldn't bother). Decoding the email to allow downloading web graphics can also take significant time.

I already have an event in place to signal that the thread should terminate and this can be checked in many more places but I don't want to hang around waiting for to long for the thread to give up.

BTW the reason I do it this way is that when sorted there will be a separate app dedicated to downloading / sending emails. I don't care about it taking time to download pretty pictures - its waste of time is acceptable, I don't like for me or other users of the app (and remember its multi user) having to hang around waiting for the junk, and for those poor souls still on dial up I don't want them having their connection dialing every time they look at an email. It was Yahoo groups emails behaviour that prompted this design way back.

Roy Lambert
Tue, Aug 25 2009 1:37 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< I would agree with you but for the downloading web graphics. One of my
news feeds is Woodstock Wire, first there are the obligatory crap ads and
secondly there are financial graphs. With redirection time included
downloading a single graph can take 30 secs (BT upto 8Mb connection, on dial
up I just wouldn't bother). Decoding the email to allow downloading web
graphics can also take significant time. >>

Yes, but don't you have the ability to stop the download in the thread ?
What are you using for your WinSock/TCP/IP  code that does the downloads ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Wed, Aug 26 2009 3:32 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

>Yes, but don't you have the ability to stop the download in the thread ?
>What are you using for your WinSock/TCP/IP code that does the downloads ?

Synapse. I'll have a look and see if I can interrupt a download. Its an option I never thought of. In my view I'd always considered each download atomic so I was downloading 5 images I can interrupt between each image but not within the download of a specific image. Its worth looking at.

Roy Lambert
Thu, Aug 27 2009 8:10 PMPermanent Link

"Lucian Radulescu"
Hi Roy,

> the app terminates before the thread

That should never happen, IMO. If you're not in full control of your
own threads, sooner or later you'll have that "b o m b" you're so
afraid of.

I try to control my threads when app is terminated in mainform's
FormCloseQuery event. I signal a global event and all my threads check
that event to shutdown themselves. In the meantime, I display a small
modal dialog, "Closing..." kind of. App goes when last thread is gone.
In some apps I go as far as to wait 30 sec and TerminateThread for
those that I know for sure can't take that long to terminate. With
database threads just use transactions and you'll be safe.

Lucian
Thu, Aug 27 2009 8:13 PMPermanent Link

"Lucian Radulescu"
> Is there a way for your
> process to occasionally check to see if the thread has been
> terminated (TThread.Terminated=True) ?

That's a race condition waiting to crash the app, if the thread has
FreeOnTerminate=true...

Lucian
Fri, Aug 28 2009 12:07 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Lucian,

<< That's a race condition waiting to crash the app, if the thread has
FreeOnTerminate=true... >>

I meant for the thread to check the condition from inside of the thread
execution.  I shouldn't have said "process", since it obviously confused the
meaning of the statement.  Also, if FreeOnTerminate was set to True, then I
wouldn't expect the process to try and control the threads (keep a list of
them, etc.) unless the threads were notifying the main thread when they were
about to terminate, sort of a "remove me from your list" type of operation.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image