On 27 Oct 2006, at 15:15, Wim Oudshoorn wrote:
It is not immediately clear to me how to solve this.
I added retain/autorelease during termination in the unix specific
version of the function to match the existing mechanism in the
windows specific version.
But before I spent to much time thinking about that, I want an opinion
about the following:
The current code can (and sometimes will) throw a
NSTaskDidTerminate notification
in a different thread than the thread that started the task.
Personally I
prefer if the thread starting the task is the same thread as the
thread
sending the notification. But maybe there are good reason for this.
(One reason of course being that the thread that started a task
can already have exited. But those tasks can be moved in a general
pool.)
Yes, the reason termination can be handled by any thread is because a
task can continue to exist after the thread which created it has exited.
Alternative schemes seem unpalatable ... as they add complexity
(keeping track of which thread a task 'belongs' to and making sure a
notification is only sent in that thread) and have no good behavior
in the case where the thread exits ... would we never send the
notification or would we send it to some other thread?
Additionally, there is the issue of portability/compatibility ... it
would seem a bad idea to build in a behavior (and have code depend on
it) which is not present in MacOS-X. While I don't know for sure
what MacOS-X does with task notifications, the documentation does say
that the notification is posted via the default center, and the
NSNotificationCenter documentation says 'In a multithreaded
application, notifications are always delivered in the thread in
which the notification was posted, which may not be the same thread
in which an observer registered itself.' ... which sounds to me like
a pretty clear warning that you should not depend on notifications
arriving in a particular thread unless you are posting the
notifications yourself and control the thread they are posted in.
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
