[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnustep-cvs] r23144 - in /libs/back/trunk: ChangeLog Source/x11/XGS
From: |
David Ayers |
Subject: |
Re: [Gnustep-cvs] r23144 - in /libs/back/trunk: ChangeLog Source/x11/XGServer.m |
Date: |
Fri, 07 Jul 2006 22:27:31 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20060423) |
Richard Frith-Macdonald schrieb:
>
> On 7 Jul 2006, at 19:28, David Ayers wrote:
>
>>
>>> URL: http://svn.gna.org/viewcvs/gnustep?rev=23144&view=rev
>>> Log:
>>> Shut down cleanly on receipt of SIGTERM
>>>
>>> Modified:
>>> libs/back/trunk/ChangeLog
>>> libs/back/trunk/Source/x11/XGServer.m
>>
>>
>> I'm not sure if we should instead add an NSInvocation of terminate: to
>> the current or even the main run loop. Calling terminate: in the signal
>> handler seems almost a bit more dangerous than killing the process as we
>> don't really know in which state we are when terminate: may start saving
>> potentially inconsistent data...
>
>
> Good idea ... while the terminate: method implementation should really
> be responsible for ensuring that it shuts down cleanly, it's certainly
> true that a signal could hit a delicate point and cause problems.
> Probably the only way to be really safe would be to add a mechanism to
> NSRunLoop to handle this ... such that a signal handler can set some
> value that the run loop would know how to deal with. Unless the run
> loop and signal mechanisms cooperate there is always going to be a
> chance that truing to manipulate the run loop within a signal handler
> could cause problems.
Indeed. The mechanism also needs to take into account that termination
can be aborted so there might be a need for some cleanup also.
>> I'm also considering whether it would be wise to remove the handler
>> during the handling.
>
>
> Perhaps blocking SIGTERM rather than just removing the handler would be
> good?
Yes, that sounds better.
Cheers,
David