[Ace-users] [ace-users] RE : RE : RE : Notify in handle_signal

Tue Feb 12 07:46:01 CST 2008

I didn't try but it looks like the unbounded notification queue won't
solve the issue. Since this is not a trivial structure it is mutex
protected.... hence not compatible with the fact I want to call it from
handle_signal.

In my case I don't care if I miss a few notifications when the pipe is
not empty because I have a loop over waitpid in handle_exception. But in
handle_signal I must be sure I call notify when the pipe is empty. One
solution would be to check in handle_signal if there is something to
read from the notification pipe (with a select for instance), and call
notify *only* when there is nothing to read (ie the pipe is empty). The
problem is the notification_pipe is protected and not public

Philippe

-----Original Message-----
From: Johnny Willemsen [mailto:jwillemsen at remedy.nl] 
Sent: Tuesday, February 12, 2008 1:58 PM
To: ZXERASOGE002, Ext; ace-users at cse.wustl.edu
Subject: RE: [ace-users] RE : RE : Notify in handle_signal

Hi,

You have to add the define to your config.h file (as first line).

Johnny

> I probably should have started by this, but this deadlock is actually
> happening.
> 
> I am using ACE 5.5, on RedHat EL 4, kernel Linux 2.6.9-55.0.2.ELsmp.
> 
> This program is a process manager, and can be told to kill all its
> children process, which in turn produce a lot of SIGCHILD. At line
314,
> the method handle_signal does this: getReactor()->notify( this );
> Using gdb when the program is frozen, we get the following backtrace:
> 
> (gdb) bt
> #0  0x0000003dffec09d0 in __write_nocancel () from /lib64/libc.so.6
> #1  0x00002aaaaab642da in ACE::send (handle=5, buf=0x7fff0ec75790,
> n=16,
> timeout=Variable "timeout" is not available.
> ) at ../../ace/OS_NS_unistd.inl:1343
> #2  0x00002aaaaabe36ef in ACE_Select_Reactor_Notify::notify
> (this=0x1089afa0, event_handler=0x108bd780, mask=4,
>     timeout=0x0) at ../../ace/Pipe.inl:26
> #3  0x00002aaaaab728d4 in
> ACE_Select_Reactor_T<ACE_Reactor_Token_T<ACE_Token> >::notify
> (this=Variable "this" is not available.
> )
>     at ../../ace/Select_Reactor_T.cpp:221
> #4  0x000000000046508f in ACALC::ProcessusManager::handle_signal
> (this=0x108bd780, signum=17, si=0x7fff0ec75a50,
>     ut=0x7fff0ec75920)
>     at xxxxxxxxxxxxxxx/processManager.cpp:314
> #5  0x00002aaaaabebb90 in ACE_Sig_Handler::dispatch (signum=17,
> siginfo=0x7fff0ec75a50, ucontext=0x7fff0ec75920)
>     at ../../ace/Signal.cpp:429
> #6  <signal handler called>
> 
> 
> 
> Johnny,
> When I greped on the ace source dir, I didn't find any reference to
> ACE_HAS_REACTOR_NOTIFICATION_QUEUE in the config files, only in the
> source files, so I guess the code for the unbounded notification queue
> is not compiled in my case. Do I need to modify the config files by
> hand
> to activate this ?
> 
> >From what I understand, this code only send one notification through
> the
> pipe at a time, is that correct ?
> That would solve the problem.
> 
> Thank you,
> Philippe
> 
> 
> -----Original Message-----
> From: Johnny Willemsen [mailto:jwillemsen at remedy.nl]
> Sent: Tuesday, February 12, 2008 11:05 AM
> To: ZXERASOGE002, Ext
> Subject: Re: [ace-users] RE : Notify in handle_signal
> 
> 
> Hi,
> 
> Check ACE_HAS_REACTOR_NOTIFICATION_QUEUE
> 
> Johnny
> 
> "ZXERASOGE002, Ext" <ext.zxerasoge002 at astrium.eads.net> wrote in
> message
> news:<mailman.3582.1202807136.5286.ace-users at mail.cse.wustl.edu>...
> 
> 
> Does anyone agree/disagree there is an issue here ?
> I would really appreciate your help about this.
> 
> Regards,
> Philippe David
> 
> 	 -----Original Message-----
> 	From: 	ZXERASOGE002, Ext
> 	Sent:	Friday, February 08, 2008 11:42 AM
> 	To:	ace-users at cse.wustl.edu
> 	Subject:	Notify in handle_signal
> 
> 	Hi,
> 	I have a question relative to the sample code in section 7.4 of
> the ACE programmer's guide p158.
> 	In a handle_signal callback, there is the following code:
> 	ACE_Reactor::instance ()->notify(this)
> 
> 	There is a potential deadlock here. If for some reason the
> process receives a lot of signals, and you don't process the
> notifications quickly enough, the pipe can be full. Since this call is
> blocking, and you are processing a signal, there is no chance your
> process will unlock from this situation.
> 
> 	What is the best way to solve this ? Making a blocking call in
> handle_signal looks like a mistake to me.
> 	In the case of notify, if the pipe is full there's is no need to
> wait, it will stay in this state as long as we are in handle_signal. I
> see that we can add a timeout to the notify call, so at least it won't
> wait forever. But as I said, if the pipe is full there is no need to
> wait, so what is the best value for this timeout ? 1ms ? Are we 100%
> sure this low value won't skip a write when the pipe is not full ?
> 	Still, it means that every signal received when the pipe is full
> will lock the process for 1ms, so we are slowing down the process
> exactly when it is not fast enough to handle all the signals received.
> Plus each handle_signal will be 1ms long, which is too much.
> 
> 	So is there a way to make a non blocking call in the notify ? or
> a way to know if the pipe is full before trying to make a write on the
> pipe ?
> 
> 	---
> 	Philippe David
> 	SOGETI High Tech

Ce courriel (incluant ses eventuelles pieces jointes) peut contenir des informations confidentielles et/ou protegees ou dont la diffusion est restreinte. Si vous avez recu ce courriel par erreur, vous ne devez ni le copier, ni l'utiliser, ni en divulguer le contenu a quiconque. Merci d'en avertir immediatement l'expediteur et d'effacer ce courriel de votre systeme. Astrium decline toute responsabilite en cas de corruption par virus, d'alteration ou de falsification de ce courriel lors de sa transmission par voie electronique.

This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
---------------------------------------------------------------------
Astrium SAS (393 341 516 RCS Paris) - Siege social: 6 rue Laurent Pichat, 75016 Paris, France