Close all threads when application closes

[KC Eric]

Hi all,

I have some threads,
one is UI thread,
one is worker thread, which uses sockets to wait for incoming messages.

I deploy it in emulator, then I click OK in the top right corner,
but then I can't deploy again, unless I closed the emulator, the error is
something like it can't output to that file.
I suspect that not all the threads were closed, and I suspect the sockets
were still waiting.
In PC, I can set thread.isBackground = true to solve this problem,
but in PPC, .net CF doesn't support thread.isBackground,
so how to solve this problem?

Thanks much!

KC Eric


--
-> ¹ª¨¬·F«l¡A¤Oª§¤W´å¡A¦h§Ö¦n¬Ù¦a«Ø³]²z·QFYP¥D¸q
-> °í¨M¿í±qÄP­ô¥|¶µªí­z¡A¥þ­±¸¨¹ê¤jÄPª÷Á`¸ô½u¡A¨«¦V¥|­Óª«¥óªì©l¤Æ
-> ¯R¿Ë®Q¿Ë³£¤£¤Îª÷ÄP­ô¿Ë XDDD
-> To be energetic to strive for the best. To build our FYP idealism in a
flourishing, rapid, perfect and efficient manner.
-> To firmly adhere to Pango's Four Statements. To comprehensively implement
The Giant Pango's Great Scheme. To stride forward to the Initialization of
The Four Objects.
-> Parents are not as close as Pango. XDDD

 

[Sergey Bogdanov]

You should implement your worker thread in this manner:

WorkerThread
{
while(isRunning)
{
...
}
}

when you set isRunning flag to true thread should accurately complete
its job. You have said that you are using Socket (I suppose blocked).
Then before exit close also socket - socket.Receive will throw an
SocketException (you should also capture it in a worker thread;
otherwise a Thread will be hanging) and after that wait till your thread
complete job. Here you are pseudo code:

1. spawn a worker thread using OpenNETCF's ThreadEx instead of Thread
(you will be needed in .Join method later)
2. set flag isRunning = false in OnClose event handler
3. WorkerThreadSocket.Close()
4. WorkerThread.Join(10000)


Best regards,
Sergey Bogdanov
http://www.sergeybogdanov.com

 

[Ginny Caughey [MVP]]

KC

In addition to Sergey's great reply, in the next version of the Compact
Framework background threads should work as you expect.

 

[KC Eric]

Thanks!

I am using non-blocking socket, I use BeginReceive(), so is it the same
logic and any changes to the Pseudo code?

Thanks much!

KC Eric

 

[Sergey Bogdanov]

Yes, the same technique applies to non-blocking sockets. A
SocketException will be thrown by the EndReceive when you close you socket.

Best regards,
Sergey Bogdanov
http://www.sergeybogdanov.com

 

[Brian Smith [MSFT]]

I should give a warning about background threads in .netcf v2 (Whidbey) --
they might not work entirely "as you expect". If a background thread is
blocked down in native code (in a pinvoke), the execution engine will not
be able to force it out to allow the process to terminate. Regrettably,
this includes threads that are in networking calls. Even non-blocking
socket calls will often cause an internal worker thread within .netcf to
end up blocked in a way that we cannot wake up. So even in v2, you will
need to play tricks like the ones discussed in this thead to allow your
application to exit cleanly.

Background threads will work "as you expect" if they are running within
managed code or blocked on a managed synchonization object (Event, Mutex,
Monitor, Sleep).

I'm not sure if this limitation has been spelled out before. It is one that
we know might be a problem but we were unable to get a good solution worked
out for this coming release.

Brian

--------------------

From: "Ginny Caughey [MVP]" <[email protected]>
References: <[email protected]>
Subject: Re: Close all threads when application closes
Date: Tue, 29 Mar 2005 11:17:48 -0500

KC

In addition to Sergey's great reply, in the next version of the Compact
Framework background threads should work as you expect.

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Ginny Caughey [MVP]]

Thanks, Brian. I wasn't aware of that limitation. That's a good warning!

 

[Dick Grier]

Hi Ginny,

This is why I implement my own background thread for Socket reads. It does
NOT use BeginReceive, so doesn't experience this problem. Naturally, the
application still needs to notify the thread to exit prior to termination.

Anyone who wants a simple example that illustrates this (VB .NET, naturally)
can send me email at (e-mail address removed).

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004. See
www.mabry.com/vbpgser4 to order.

 

[Ginny Caughey [MVP]]

Dick,

That certainly sounds like a good strategy. Asynchronous calls just don't
look so attractive when there's no way to abort them.

 

[Daniel Moth]

Brian this info is not spelled out anywhere else, thanks.

Background threads will work "as you expect" if they are running within
managed code or blocked on a managed synchonization object (Event, Mutex,
Monitor, Sleep).

You say "managed synchronization object". So if I have pinvoked and
WaitForSingleObject myself, will that thread not be woken up and shut down
when the app terminates?

Cheers
Daniel

 

[Brian Smith [MSFT]]

Daniel, you are correct: a background thread blocked on a
WaitForSingleObject within a pinvoke will NOT be automatically woken up to
allow the application to shut down. Only fully managed objects created and
waited-on through the System.Threading classes are controllable by .netcf.
This is because the .netcf execution engine itself is just like any other
application running on Windows CE and has no special access to internal OS
data structures or "backdoor" APIs. It doesn't know what a thread inside a
pinvoke is doing or what it might be blocked on. The only mechanism
available to terminate it would be the Windows TerminateThread API. Killing
a thread in this way without any way for it to clean itself up could leave
the process or the larger system in a bad state if the thread was using or
modifying shared resources (mutexes, files, etc). The dangers are
especially great when more than one AppDomain is running within a single
process.

Only the application itself knows when and how to safely exit such a thread
and .netcf will rely on the application to do so. In future releases, we
will try to fix some of the situations (such as the managed sockets case)
in which .netcf has enough knowledge to clean up safely and automatically.
But the general pinvoke case will probably remain as it is for the
foreseeable future unless the current non-solution causes more problems
that it solves. Hopefully in the future, the managed development
environment will be rich enough that pinvokes will be less necessary and
the problem will disappear.

Brian
--------------------

From: "Daniel Moth" <[email protected]>
Date: Wed, 30 Mar 2005 19:54:29 +0100

Brian this info is not spelled out anywhere else, thanks.


You say "managed synchronization object". So if I have pinvoked and
WaitForSingleObject myself, will that thread not be woken up and shut down
when the app terminates?

Cheers
Daniel

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Daniel Moth]

Brian, thank you again for the useful info.

In my opinion, the CF team should make these facts very public and at least
make sure there is a CF-specific annotation to the IsBackground property in
the documentation.

Cheers
Daniel

 

[Ginny Caughey [MVP]]

Daniel,

Good point about a warning in the docs. This behavior is not what people
will expect.

 

[Brian Smith [MSFT]]

It's public now for anyone to Google -- I mean MSN Search
But you raise a good point. I'll pass the information along to our
documentation folks. I'm not sure where the information will best fit but
it should go somewhere.

--------------------

From: "Daniel Moth" <[email protected]>
Date: Wed, 30 Mar 2005 22:47:01 +0100

Brian, thank you again for the useful info.

In my opinion, the CF team should make these facts very public and at least
make sure there is a CF-specific annotation to the IsBackground property in
the documentation.

Cheers
Daniel

This posting is provided "AS IS" with no warranties, and confers no rights.