Yes. That is exactly the case why I tried to find a better and elegant
solution.
I'm sorry that I didn't read digest version of Cocoa-dev email yesterday.
To me it was a busy day yesterday and when I went back home, I literally
went to bed ( after writing one email. )
So, I missed your great post.
Some people would say we don't need to clean up at that moment, but
generally speaking there can be a necessity of cleaning up, which is not
only about releasing memory ( well, garbage collector helps here a lot.
) but also closing network ports, or serial ports.
( Mac and iOS devices don't have serial ports, but I put it here as an
example. )
Back in 1990's I noticed that if a terminal program on one computer,
i.e. my PowerBook 140, Mac LC, IBM-compatible PC 386 processor machine I
assembled, quits without closing a port, it or the program on the other
sides could hang. Modern OS or language RunTimes seem to handle those
well compared how things were in late 80's and early 90s.
But still we want to make sure things are to be cleaned up properly, right?
But as with Cocoa and .NET, I noticed that threading model evolved to
have one main thread ( which is responsible for UI ) take the whole role
in managing UI, while other threads generally take care of more
dedicated chores which don't need to handle UI widgets. But because
sometimes it will be required, Apple provides
performSelectorOnMainThread() and MS provides Invoke() mechanism.
However, this left the problem I noticed and you described here.
MS seems to have its RunTime handles things sufficiently well. If I
don't assign a thread variable to null ( to prevent calling a method of
a null object like myThread.Join() or myTread.DoCleanUp() or whatever,
the C# .NET runtime doesn't raise an exception for accessing a member
function of a non-existing object.
Also, it seems to close a serial port.
However, this may not ensure something, like proper hand-off for the
opponent on the other side of communication channel. Or the opponent
codes can be written to handle a case when its opponent doesn't respond
anything.
But.. anyway point here is.. yes.. as we can see it, it can be a problem
under some situation.
Anyway, I will go through this mailing list digest email when I go
back home.
I don't want to miss others' great insight posted here. :)
Have a nice day, and I'm sorry for people I didn't reply to yet..
JongAm Park
On 3/13/2012 5:00 PM, cocoa-dev-requ...@lists.apple.com wrote:
Message: 11
Date: Tue, 13 Mar 2012 16:49:33 -0700
From: Jay Reynolds Freeman<jay_reynolds_free...@mac.com>
To: "Cocoa-Dev (Apple)"<cocoa-dev@lists.apple.com>
Subject: Re: [Q] Why is the threading and UI updating designed to be
done only on a main thread?
Message-ID:<7de60fad-f19f-4b03-aff9-88a781420...@mac.com>
Content-Type: text/plain; CHARSET=US-ASCII
Notwithstanding the good advice about parallel programming given earlier in
this thread, there are still possible problems. By way of illustration, a year
or two ago I submitted a bug report (#8338166) about a problem of this sort in
iOS. I will describe the problem here. (I am not looking for a workaround, I
have one -- here I am just providing a real example from the past that may be
of interest.)
Consider UIApplicationDelegate method "applicationWillTerminate:":
Multithreaded applications may not be able to use it to shut down, because of the
possibility of deadlock in communications between the main thread and other application
threads.
Suppose we have a multithreaded iOS application whose non-main threads occasionally use
"performSelectorOnMainThread:withObject:waitUntilDone:" to interact with the
main thread. Now suppose the following things happen, in this order:
1) "applicationWillTerminate:" is called (by the OS, on the main thread).
2) Immediately thereafter, before "applicationWillTerminate" has completed, some other thread calls
"performSelectorOnMainThread:withObject:waitUntilDone:", with "waitUntilDone:"'s value
set to YES.
3) Suppose the application needs to get the other thread to do some shut-down work -- the
kind of thing that is supposed to happen in "applicationWillTerminate:"
4) We now have a problem with deadlock. The application*cannot* communicate with the other thread from inside
"applicationWillTerminate:", because the other thread is waiting for "performSelector ..." to run,
and that won't happen until "applicationWillTerminate:" has itself returned. And if the application posts an
event to the other thread and then returns from "applicationWillTerminate:", it is highly likely that the OS
will terminate the application before the other thread has had a chance to act. So there is no reliable way to get the
other thread to do its cleanup.
The point here is that since "applicationWillTerminate:" is called
asynchronously from the point of view of the app, the app can*NEVER* communicate with
any thread that may have to do clean-up work, by any communication protocol that requires
the other thread to wait for the main thread to do something, for fear of a deadlock such
as I have just described. That is a substantial restriction.
There are certainly other ways to do an iOS app shutdown, but this case illustrates the
kind of deadlock that can happen if you do not think carefully about how things interact.
The original intended use of "applicationWillTerminate:" is indeed a setup for
deadlock to happen.
One should be on the lookout for similar situations with other iOS or MacOS
methods.
-- Jay Reynolds Freeman
---------------------
jay_reynolds_free...@mac.com
http://web.mac.com/jay_reynolds_freeman (personal web site)
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
