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

Tue Feb 12 06:58:28 CST 2008

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
> 
> _______________________________________________
> ace-users mailing list
> ace-users at mail.cse.wustl.edu
> http://mail.cse.wustl.edu/mailman/listinfo/ace-users