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

[ZXERASOGE002, Ext]

Hi

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