Close all threads when application closes

KC Eric

unread,

Mar 29, 2005, 9:51:10 AM3/29/05

to

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

--
-> 鼓足幹勁，力爭上游，多快好省地建設理想FYP主義
-> 堅決遵從鵬哥四項表述，全面落實大鵬金總路線，走向四個物件初始化
-> 爹親娘親都不及金鵬哥親 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

unread,

Mar 29, 2005, 10:15:34 AM3/29/05

to

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]

unread,

Mar 29, 2005, 11:17:48 AM3/29/05

to

KC

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

--
Ginny Caughey
.Net Compact Framework MVP

"KC Eric" <kceric@nospam> wrote in message
news:O30A86GN...@TK2MSFTNGP14.phx.gbl...

KC Eric

unread,

Mar 29, 2005, 11:34:52 AM3/29/05

to

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" <sergey....@gmail.com> ???
news:eiw7oIHN...@TK2MSFTNGP10.phx.gbl ???...

Sergey Bogdanov

unread,

Mar 29, 2005, 1:03:01 PM3/29/05

to

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

Brian Smith [MSFT]

unread,

Mar 29, 2005, 8:28:53 PM3/29/05

to

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]" <ginny.caug...@wasteworks.com>
>References: <O30A86GN...@TK2MSFTNGP14.phx.gbl>
>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.
>
>--
>Ginny Caughey
>.Net Compact Framework MVP
>
>
>"KC Eric" <kceric@nospam> wrote in message
>news:O30A86GN...@TK2MSFTNGP14.phx.gbl...
>> 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
>>

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

Ginny Caughey [MVP]

unread,

Mar 29, 2005, 8:42:01 PM3/29/05

to

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

--
Ginny Caughey
.Net Compact Framework MVP

"Brian Smith [MSFT]" <briansm@nospam_microsoft.com> wrote in message
news:J0IbYfMN...@TK2MSFTNGXA03.phx.gbl...

Dick Grier

unread,

Mar 30, 2005, 11:07:43 AM3/30/05

to

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 dick_...@msn.com.

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]

unread,

Mar 30, 2005, 1:10:50 PM3/30/05

to

Dick,

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

--
Ginny Caughey
.Net Compact Framework MVP

"Dick Grier" <dick_gri...@msn.com> wrote in message
news:%23QrpaKU...@TK2MSFTNGP14.phx.gbl...

Daniel Moth

unread,

Mar 30, 2005, 1:54:29 PM3/30/05

to

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
--
http://www.danielmoth.com/Blog/

"Brian Smith [MSFT]" <briansm@nospam_microsoft.com> wrote in message
news:J0IbYfMN...@TK2MSFTNGXA03.phx.gbl...

Brian Smith [MSFT]

unread,

Mar 30, 2005, 3:01:29 PM3/30/05

to

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" <dmo...@hotmail.com>
>Date: Wed, 30 Mar 2005 19:54:29 +0100

Daniel Moth

unread,

Mar 30, 2005, 4:47:01 PM3/30/05

to

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
--
http://www.danielmoth.com/Blog/

"Brian Smith [MSFT]" <briansm@nospam_microsoft.com> wrote in message

news:bNm%23GNWNF...@TK2MSFTNGXA03.phx.gbl...

Ginny Caughey [MVP]

unread,

Mar 30, 2005, 5:40:45 PM3/30/05

to

Daniel,

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

--
Ginny Caughey
.Net Compact Framework MVP

"Daniel Moth" <dmo...@hotmail.com> wrote in message
news:%23KZplHX...@TK2MSFTNGP10.phx.gbl...

Brian Smith [MSFT]

unread,

Mar 31, 2005, 9:03:45 PM3/31/05

to

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" <dmo...@hotmail.com>

>Date: Wed, 30 Mar 2005 22:47:01 +0100