f



Re: [tao-users] [Event handling] : [deadlock problem with TAO/event handling]

Sankar-

>     TAO VERSION: 1.3.1
>     ACE VERSION: 5.3.1

Would it be possible for you to upgared to 1.4 and give your test a 
whirl? Please see

http://deuce.doc.wustl.edu/Download.html

for details on how to download. 


Thanks
bala

> 
>     HOST MACHINE and OPERATING SYSTEM: Windows 2000
>         If on Windows based OS's, which version of WINSOCK do you
>         use?:
> 
>     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>     COMPILER NAME AND VERSION (AND PATCHLEVEL): 
> 	Visual Studio .NET 2003 (7.1.3088)
> 
>     AREA/CLASS/EXAMPLE AFFECTED: Event handling
> 
>     DOES THE PROBLEM AFFECT:
>         COMPILATION? NO
>             If so, what do your $ACE_ROOT/ace/config.h and
>             $ACE_ROOT/include/makeinclude/platform_macros.GNU contain?
>         LINKING? NO
>             On Unix systems, did you run make realclean first?
>         EXECUTION? YES
>         OTHER (please specify)?
> 
> 
>     SYNOPSIS:
> 
>     Suspected deadlock when using TAO (using a TP reactor) 
>     in conjunction with a WFMO reactor for other event processing.
> 
>     DESCRIPTION:
> 
> I am facing a suspected deadlock situation and trying to investigate.
> I need to do more work to nail down the problem, but I need some help
> to know whether I am doing things right. I give some contextual 
> information below (which may be skipped for a quick reading)
> followed by a set of general questions on TAO event handling.
> 
> The context is this:
> 
> 1. A CORBA application using 3 threads in total: 
> 
>    a. one for dispatching CORBA requests (calls ORB::run())
> 
>    b. one which runs a reactor event loop primarily 
>       to process application socket data 
>       (calls ACE_Reactor::instance()->run_event_loop())
> 
>    c. one which processes a queue (Q) of application events.
> 
> 2. Thread (a) does NOT make CORBA client requests.
>    Threads (b) and (c) do, however.
> 
> 3. The process seems to have deadlocked with 
> 
>    (a) waiting for the client leader to complete
> 
>    (b) which has sent a CORBA request out and is waiting
>    for a response seems to have called an event loop
>    which resulted in dispatching a CORBA upcall 
>    which in turn resulted in a wait on Q
> 
>    (c) waiting for a CORBA response (the server has already
>    sent the response; but (c) seems to have not read it yet)
> 
> Given this context I have a set of questions:
> 
> 1. Can one use a separate reactor (one returned by 
>    ACE_Reactor::instance which happens to be a WFMO
>    reactor) in conjunction with TAO which uses a TP
>    reactor?
>  
> 2. The WFMO reactor seems to dispatch CORBA calls 
>    in addition to the application specific events
> 
> 
> 3. Are there examples/tests under the TAO build tree
>    which depict application event integration with TAO?
> 
> 
> 4. Is there any way to tell ACE so that ACE_Reacto::instance()
>    returns a specific instance (e.g., that used by the ORB)?
>    And, in general, how do I specify the reactor type (WFMO or TP) 
>    to ACE?
> 
> 
>     REPEAT BY:
> 
>     SAMPLE FIX/WORKAROUND:
> 













































































0
bala5913 (162)
1/20/2004 5:51:10 PM
comp.soft-sys.ace 20326 articles. 1 followers. marlow.andrew (167) is leader. Post Follow

0 Replies
470 Views

Similar Articles

[PageSpeed] 4

Reply:

Similar Artilces:

Re: [tao-users] [Event handling] : [deadlock problem with TAO/event handling] #2
Sankar- > 1. Can one use a separate reactor (one returned by > ACE_Reactor::instance which happens to be a WFMO > reactor) in conjunction with TAO which uses a TP > reactor? The question I would ask is why? You get WFMO since you probably are on Win32 platform. But your application would get an instance of Select_Reactor if you are *nix based platforms. There is no harm in using the reactor returned, but they have limitations, which is why we have carefully chosen to have TP_Reactor as the default. > 2. The WFMO reactor seems to dispatch CORBA calls > in ...

[tao-users] [Event handling] : [deadlock problem with TAO/event handling]
TAO VERSION: 1.3.1 ACE VERSION: 5.3.1 HOST MACHINE and OPERATING SYSTEM: Windows 2000 If on Windows based OS's, which version of WINSOCK do you use?: TARGET MACHINE and OPERATING SYSTEM, if different from HOST: COMPILER NAME AND VERSION (AND PATCHLEVEL): Visual Studio .NET 2003 (7.1.3088) AREA/CLASS/EXAMPLE AFFECTED: Event handling DOES THE PROBLEM AFFECT: COMPILATION? NO If so, what do your $ACE_ROOT/ace/config.h and $ACE_ROOT/include/makeinclude/platform_macros.GNU contain? LINKING? NO O...

[tao-users] Re: [ace-users] How to use c++ native exception handling instead of ACE's while building ACE+TAO
Hi, >> My only guess is that all of the libs you are linking in your >> builds were not compiled with a consistent set of options. Right, my recommendation would be to completely blow away your existing ACE+TAO x.5 directory, download a fresh version, and start from a clean slate. It sounds like you may have things lying around from previous build attempts. Thanks, Doug -- Dr. Douglas C. Schmidt Professor and Associate Chair Electrical Engineering and Computer Science TEL: (615) 343-8197 Institute for Software Integrated Systems...

RE: [ace-users] Re: [tao-users] Problem with removing event handler
Hi Doug, That's what I started looking at after I found the one version worked because that's what looked to be failing in the reactor source code, and my get_handle was indeed the problem. Both versions of remove_handler now work correctly. Thanks! Rob. > -----Original Message----- > From: owner-ace-users@cse.wustl.edu > [mailto:owner-ace-users@cse.wustl.edu] On Behalf Of Douglas C. Schmidt > Sent: Thursday, September 11, 2003 7:50 AM > To: Rob Eger > Cc: tao-users@cs.wustl.edu; ace-users@cs.wustl.edu > Subject: [ace-users] Re: [tao-users] Problem with remov...

[ace-users] RE: [tao-users] Problem with removing event handler
A bit more info. From what I can tell, handle_close is never getting called. Am I understanding correctly that it should be getting called as part of the remove_handler call? Rob. > -----Original Message----- > From: owner-tao-users@cse.wustl.edu > [mailto:owner-tao-users@cse.wustl.edu] On Behalf Of Rob Eger > Sent: Tuesday, September 09, 2003 4:07 PM > To: tao-users@cs.wustl.edu; ace-users@cs.wustl.edu > Subject: [tao-users] Problem with removing event handler > > > TAO VERSION: 1.3 > ACE VERSION: 5.3 > > HOST MACHINE and OPERATING SYSTE...

[ace-users] Re: [tao-users] Problem with removing event handler #2
Hi Rob, > A bit more info. From what I can tell, handle_close is never getting > called. Am I understanding correctly that it should be getting called as > part of the remove_handler call? Yes, as long as you don't pass the ACE_Event_Handler::DONT_CALL to remove_hander(), which it appears that you're doing ;-). Please see Chapters 3 and 4 of C++NPv2 <www.cs.wustl.edu/~schmidt/ACE/book2/> for all the gory details. Take care, Doug ...

[ace-users] RE: [tao-users] Problem with removing event handler #2 #3
Hi Doug, I figured that out, and removed ACE_Event_Handler::DONT_CALL from my remove_handler call this morning. As far as I can tell handle_close is still not getting called. Rob. > -----Original Message----- > From: Douglas C. Schmidt [mailto:schmidt@cse.wustl.edu] > Sent: Wednesday, September 10, 2003 11:47 AM > To: Rob Eger > Cc: tao-users@cs.wustl.edu; ace-users@cs.wustl.edu > Subject: Re: [tao-users] Problem with removing event handler > > > > Hi Rob, > > > A bit more info. From what I can tell, handle_close is > never getting > >...

[ace-users] Re: [tao-users] Problem with removing event handler #2 #2
Hi Rob, > I figured that out, and removed ACE_Event_Handler::DONT_CALL from my > remove_handler call this morning. As far as I can tell handle_close is > still not getting called. Perhaps you're not defining handle_close() with the right signature? At any rate, there's no good reason for this not to work, so I recommend you crank up the debugger and figure out what's going on. thanks, doug ...

[ace-users] RE: [tao-users] Problem with removing event handler #2 #4
Ok... Found a fix, but don't know why it works and the original way I was doing it doesn't. The call to register_handler was returning 0, which means all is okay. However, the call to remove_handler was returning -1, which in looking at the reactor source code explains why handle_close is never getting called. So, I tried the version of remove_handler where I pass in the handle that I'm watching events on, and, lo and behold, it all works - handle_close is called, remove_handler returns 0, no crashes, etc. Not sure why int result = orb->orb_core()->reactor()->remove...

[tao-users] Problem building tao Name Service and Event Service in ARM9 with TAO-1.6.8 and ACE-5.6.8
--000e0cd25acc80e6b30464c1eca4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit TAO VERSION: 1.6.8 ACE VERSION: 5.6.8 HOST MACHINE and OPERATING SYSTEM: Athlon(TM) 1200 Mhz, RAM DIMM 256Mb, HDD 20 Gb Linux Debian 2.6.18-6-686 TARGET MACHINE and OPERATING SYSTEM: ARM926EJ-S with kernel linux embebed 2.4.20-celf3 THE $ACE_ROOT/ace/config.h FILE: config-linux.h THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE: platform_ARM.GNU (see in http://forum.huihoo.com/archive/viewtopic.php?sta...

Re: [tao-users] Integrating ACE/TAO with existing signal-handling code
TAO VERSION: 1.5.4 ACE VERSION: 5.5.4 HOST MACHINE and OPERATING SYSTEM: i86x, FC6 Linux TARGET MACHINE and OPERATING SYSTEM, if different from HOST: COMPILER NAME AND VERSION (AND PATCHLEVEL): I installed these from the RPMs at http://dist.bonsai.com/ken/ace_tao_rpm/FC6.i386/5.5.4-1/ . THE $ACE_ROOT/ace/config.h FILE: Available on request (it's whatever Ken Sedgwick used for that build). THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE: Ditto. CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features: D...

RE: [tao-users] Handle CORBA and Non-CORBA events
Hello Steve, >> It was simpler to use the Pull model and the >> ACE_Event_Handler+Reactor->schedule_timer() (yes the original >> implementations already used the ACE lib). >I think I see. When the timer fired, your event handler's >handle_timeout() method would pull an event. Is that >right? You're right. >> Since the Pull model is not supported we have to change these processes, >> basically each of them should become a CORBA server. Could someone point me >> out some examples/tests where this is demonstrated in TAO (handle CORBA ...

RE: [tao-users] trouble about ACE Exception Handling Macros in programs based on TAO
Hi, This really looks ancient generated skeleton code and we really lack more information. To ensure that we have proper version/platform/compiler information, please make sure you fill out the appropriate problem report form (PRF), which is in $ACE_ROOT/PROBLEM-REPORT-FORM $TAO_ROOT/PROBLEM-REPORT-FORM or in $ACE_ROOT/BUG-REPORT-FORM $TAO_ROOT/BUG-REPORT-FORM in older versions of ACE+TAO. Make sure to include this information when asking any questions about ACE+TAO since otherwise we have to "guess" what version/platform/compiler/options you've using, w...

[ace-users] Re: [tao-users] Re: A client thread assigned to handle a server request
Hi Ivo, >> Sorry for the comment but as for TAO 1.3a patch level 12 this >> MT_NOUPCALL did not work 100% as expected. I don't remember what >> the problem was, but this was the motivation for us to change our >> code to create 2 ORBs instead of 1 ( one to handle client requests >> and one to handle server requests, in order to decouple >> server/client handling). I'll let the OCI folks handle this since they are the ones who added MT_NOUPCALL. Thanks, Doug >> Regards, >> Ivo >> >> > -----Or...

Re: [tao-users] Re: ACE/TAO call back problem
Hi > > HOST MACHINE: Redhat 9 > > TARGET MACHINE: Windows 2000 SP4 > > COMPILER NAME AND VERSION (AND PATCHLEVEL): C++ Builder 6.0 build > > 10.155, gcc 3.2.2 > > > > > > AREA/CLASS/EXAMPLE AFFECTED: > > Callback from server to client > > > > > > DOES THE PROBLEM AFFECT: > > COMPILATION? > > no > > LINKING? > > no > > EXECUTION? > > yes > > > > > > SYNOPSIS: > > Sever can not call back client. This call simply fails. All machines > > ...

Re: [tao-users] Re: ACE/TAO call back problem #2
This is a multipart message in MIME format. --=_alternative 0025F9B5C1256F63_= Content-Type: text/plain; charset="us-ascii" I had a similar problem a long time ago :-). In my case, the IOR passed by the client to the server contained a hostname which was unknown in the server. We did not use a DNS. The server used a hosts file. In our case, using ORBDottedDecimalAddresses 1 was the solution. Best wishes --=_alternative 0025F9B5C1256F63_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="sans-serif">I had a similar p...

[ace-bugs] Re: [ace-users] How to use c++ native exception handling instead of ACE's while building ACE+TAO
Hi, To ensure that we have proper version/platform/compiler information, please make sure you fill out the appropriate problem report form (PRF), which is in $ACE_ROOT/PROBLEM-REPORT-FORM $TAO_ROOT/PROBLEM-REPORT-FORM or in $ACE_ROOT/BUG-REPORT-FORM $TAO_ROOT/BUG-REPORT-FORM in older versions of ACE+TAO. Make sure to include this information when asking any questions about ACE+TAO since otherwise we have to "guess" what version/platform/compiler/options you've using, which is error-prone and slows down our responsiveness. > I know we can set except...

RE: [tao-users] Request Handling in TAO
Hi, To ensure that we have proper version/platform/compiler information, please make sure you fill out the appropriate problem report form (PRF), which is in $ACE_ROOT/PROBLEM-REPORT-FORM $TAO_ROOT/PROBLEM-REPORT-FORM or in $ACE_ROOT/BUG-REPORT-FORM $TAO_ROOT/BUG-REPORT-FORM in older versions of ACE+TAO. Make sure to include this information when asking any questions about ACE+TAO since otherwise we have to "guess" what version/platform/compiler/options you've using, which is error-prone and slows down our responsiveness. When you use a thread pool in y...

[ace-users] [tao-users] Problem linking ACE/TAO
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPart_000_0042_01C67435.B64C4BE0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Hello, I have an application using ACE/TAO and I get a linking error trying to = build executable. ACE/TAO VERSION: 5.5 / 1.5 OPERATING SYSTEM: Win 2000 SP 4 COMPILER NAME and VERSION: VC++ 2005 Standard Edition CONTENTS of $ACE_ROOT/ace/config.h: #define ACE_HAS_STANDARD_CP...

[tao-users] [ace-users] Problem linking ACE/TAO
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPart_000_0042_01C67435.B64C4BE0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Hello, I have an application using ACE/TAO and I get a linking error trying to = build executable. ACE/TAO VERSION: 5.5 / 1.5 OPERATING SYSTEM: Win 2000 SP 4 COMPILER NAME and VERSION: VC++ 2005 Standard Edition CONTENTS of $ACE_ROOT/ace/config.h: #define ACE_HAS_STANDARD_CP...

Re: [ace-users] Re: [tao-users] Re: difficulties compling TAO with mingw and msys
Hi, Great, when we get time we will try to upgrade to a newer version of MinGW, but it is still a candidate. Just keep an eye on the scoreboard, when we upgrade you will see it there. As you can see on the scoreboard, there are no issues with the 3.2.3 version Regards, Johnny Willemsen Remedy IT Leeghwaterstraat 25 2811 DT Reeuwijk The Netherlands www.theaceorb.nl / www.remedy.nl "William Lederer" <wgl@localhost.localdomain> wrote in message news:<m3pt4yrtfx.fsf@localhost.localdomain>... > Thanks! > > I followed your advice in your earli...

RE: [ace-users] How to use c++ native exception handling instead of ACE's while building ACE+TAO
Hi, The files hand-crafted from pseudo IDL in the ORB are all using -Ge 1, the same as the orbsvcs files in your use case, so there should be no conflict. When you say you've set exceptions=1, does that mean for orbsvcs or for the TAO build as well? We are in the process of dropping support for ACE's exception handling, and as I understand it, in the version of ACE+TAO that you have, ACE exception handling should not be possible. My own workspace always uses native exception handling (and the IDL compiler option -Ge 1), and I have no build problems at any time. My only gues...

RE: [tao-users] Re: [ace-users] Re: Announcing the release of the new beta (ACE-5.4.10, TAO-1.4.10 and CIAO-0.4.10)
Hi, > > >> We encourage you to download the new beta, use it with your > > >> applications, and let us know soon if you encounter any problems > > >> since we plan to cut the x.5 release by February 28th. > > > > As per Wallace's comments, we have an aggressive schedule > for the x.5 > > release to meet the needs of some major sponsors. If > people can give > > x.4.10 a "test drive" in the next couple of days and report problems > > they encounter we'll try to ensure that we fix any >...

[tao-bugs] Re: [tao-users] ACE 5.4.0 TAO 1.4 build problems in orbsvcs
Hi Bill, It looks to me like you haven't built Kokyu, which is in $ACE_ROOT/Kokyu/ Please try building this first and then build TAO. Chris/Venkita/Bala/Don, can we please figure out a way to keep the lack of Kokyu being built from causing the rest of orbsvcs from failing?! Thanks, Doug > Makefile: > /export/home/bcassan/ACE_wrappers/TAO/orbsvcs/orbsvcs/Makefile.RTKokyuEvent > > g++ -W -Wall -Wpointer-arith -pipe -O3 -D_REENTRANT > -I/export/home/bcassan/ACE_wrappers -I/export/home/bcassan/ACE_wrappers/TAO > -DACE_NDEBUG -DACE_USE_RCSID=0 -DACE...

Web resources about - Re: [tao-users] [Event handling] : [deadlock problem with TAO/event handling] - comp.soft-sys.ace

Resources last updated: 2/16/2016 3:52:02 PM