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
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)
> 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?
> 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
> 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)
> > 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?
>>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)
>>>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?
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.
>> 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.
>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.caughey.onl...@wasteworks.com> >>References: <O30A86GNFHA.1...@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.
>>> 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.
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_gr...@msn.com.
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.
> 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_gr...@msn.com.
> 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.
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?
>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.caughey.onl...@wasteworks.com> >>References: <O30A86GNFHA.1...@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.
>>> 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.
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 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?
>"Brian Smith [MSFT]" <briansm@nospam_microsoft.com> wrote in message >news:J0IbYfMNFHA.3320@TK2MSFTNGXA03.phx.gbl... >>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.caughey.onl...@wasteworks.com> >>>References: <O30A86GNFHA.1...@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.
>>>> 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.
This posting is provided "AS IS" with no warranties, and confers no rights.
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.
> 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" <dmot...@hotmail.com> >>Date: Wed, 30 Mar 2005 19:54:29 +0100
>>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?
>>"Brian Smith [MSFT]" <briansm@nospam_microsoft.com> wrote in message >>news:J0IbYfMNFHA.3320@TK2MSFTNGXA03.phx.gbl... >>>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.caughey.onl...@wasteworks.com> >>>>References: <O30A86GNFHA.1...@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.
>>>>> 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.
> This posting is provided "AS IS" with no warranties, and confers no > rights.
> 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.
> "Brian Smith [MSFT]" <briansm@nospam_microsoft.com> wrote in message > news:bNm%23GNWNFHA.1796@TK2MSFTNGXA03.phx.gbl... >> 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" <dmot...@hotmail.com> >>>Date: Wed, 30 Mar 2005 19:54:29 +0100
>>>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?
>>>"Brian Smith [MSFT]" <briansm@nospam_microsoft.com> wrote in message >>>news:J0IbYfMNFHA.3320@TK2MSFTNGXA03.phx.gbl... >>>>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.caughey.onl...@wasteworks.com> >>>>>References: <O30A86GNFHA.1...@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.
>>>>>> 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.
>> This posting is provided "AS IS" with no warranties, and confers no >> rights.
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.
>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.
>"Brian Smith [MSFT]" <briansm@nospam_microsoft.com> wrote in message >news:bNm%23GNWNFHA.1796@TK2MSFTNGXA03.phx.gbl... >> 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" <dmot...@hotmail.com> >>>Date: Wed, 30 Mar 2005 19:54:29 +0100
>>>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?
>>>"Brian Smith [MSFT]" <briansm@nospam_microsoft.com> wrote in message >>>news:J0IbYfMNFHA.3320@TK2MSFTNGXA03.phx.gbl... >>>>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.caughey.onl...@wasteworks.com> >>>>>References: <O30A86GNFHA.1...@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.
>>>>>> 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.
|
