Andre Poenitz wrote:
> On Mon, Mar 22, 2004 at 10:37:30AM +, Angus Leeming wrote:
>> and that the 'real' code handling the error is then handled in the
>> main program loop. However, I don't see anyway to code that up
>> without using throw/catch.
>
> Destructor of a static singleton?
Actual
On Mon, Mar 22, 2004 at 10:37:30AM +, Angus Leeming wrote:
> and that the 'real' code handling the error is then handled in the
> main program loop. However, I don't see anyway to code that up
> without using throw/catch.
Destructor of a static singleton?
Andre'
On Mon, Mar 22, 2004 at 12:36:48PM +, Angus Leeming wrote:
> Let's be careful here. Could you check the attached patch? If you're
> happy, I'll commit it.
Looks magic
john
--
"Spammers get STABBED by GOD." - Ron Echeverri
John Levon wrote:
> Actually I've changed my mind, your code (modulo SIGPIPE issue) is
> fine, with one change: we should do the emergencyCleanup *first* so
> if the lyxerr *does* have problems, then we've at least made an
> effort to save the files ASAP.
Makes sense.
> I think it's fine to do su
On Mon, Mar 22, 2004 at 10:37:30AM +, Angus Leeming wrote:
> > Not really happy actually. If we get a SIGPIPE and a SIGSEGV, we'd
> > lose the SIGSEGV afaics.
>
> Hence my statement that we should remove the SIGPIPE. Ie, SIGPIPE
> signals should not be handled by error_handler. In fact we do
John Levon wrote:
> On Mon, Mar 22, 2004 at 09:28:01AM +, Angus Leeming wrote:
>
>> John Levon wrote:
>> >> Or should the code in child_handler be truly trivial:
>> > Yes.
>>
>> John, I take it that you're (almost) happy with the existing signal
>> handling code in error_handler below. To my
On Mon, Mar 22, 2004 at 09:28:01AM +, Angus Leeming wrote:
> John Levon wrote:
> >> Or should the code in child_handler be truly trivial:
> > Yes.
>
> John, I take it that you're (almost) happy with the existing signal
> handling code in error_handler below. To my mind it needs only a
> han
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | John Levon wrote:
Or should the code in child_handler be truly trivial:
>>> Yes.
>>
> | John, I take it that you're (almost) happy with the existing
> | signal handling code in error_handler below. To my mind it nee
Angus Leeming <[EMAIL PROTECTED]> writes:
| John Levon wrote:
>>> Or should the code in child_handler be truly trivial:
>> Yes.
>
| John, I take it that you're (almost) happy with the existing signal
| handling code in error_handler below. To my mind it needs only a
| handling_error flag to ensu
John Levon wrote:
>> Or should the code in child_handler be truly trivial:
> Yes.
John, I take it that you're (almost) happy with the existing signal
handling code in error_handler below. To my mind it needs only a
handling_error flag to ensure that it handles multiple signals
safely. (The SIGP
John Levon wrote:
> That's correct. Very (very) few system calls are usable in a signal
> context. This includes anything printf-like.
>
> You can refer to the UNIX standards for more info, but basically,
> setting a sigatomic_t variable to TRUE or equivalent is the way to
> go.
I've been readin
On Fri, Mar 19, 2004 at 06:21:16PM +, Angus Leeming wrote:
> Attached is a patch to use the SIGCHLD signal instead of this Timeout. The
Good man. You made the UNIX bunnies happy (that is, me).
> static void child_handler(int err_sig)
> {
> switch (err_sig) {
> case SIGCHLD:
12 matches
Mail list logo
