f



Re: [ace-bugs] Re: [ace-users] RE: Module->open() #2

Hi,

>> I guess I'm just pushing the limits a bit and trying to avoid
>> writing a whole bunch of new code.

This is a time-honored way in which ACE evolves.  
  
>> I view ACE_Stream/Module/Task as a good vehicle for a
>> component-based design of network protocol processing that includes
>> complex/stateful behaviors.

Right, I agree.

>> The Streams framework has components and behaviors relevant to
>> dynamically configuring services which consist of a set of
>> cooperating sub-objects.  I understand that the assumption in
>> Streams is that these sub-objects are linearly (bi-directonally)
>> associated and that they contain exactly two ACE_Tasks.

Right, each ACE_Module contains two ACE_Tasks, though an ACE_Task can
contain as many pointers to ACE_Tasks as it wants, thereby making it
possible to have arbitrarily complex plumbing.

>> But in fact this there's not much in the code that requires this to
>> be the case, and the System V Streams / PIPE&FILTER abstraction
>> doesn't have to be taken quite so litterally.  E.g., what if I had
>> three tasks in a module where the third task dynamically monitored
>> the queue sizes of the other two?

You could either subclass from ACE_Module and add another ACE_Task to
it or you could use the technique I described above and have one or
both of the ACE_Tasks contain other ACE_Tasks.

>> E.g., what if I had a Task abstraction that generated polymorphic
>> events (perhaps Message_Blocks) for components that are
>> out-of-band, e.g., a graphical display?

Again, you could program this stuff using techniques like I described
above.

>> The Module containing the Tasks seems like a good place to manage
>> the extra resources/capabilities mentioned above and/or be a
>> liaison with the rest of the world.

If you'd like to add these capabilities to ACE and contribute them to
us that would be great!  The ACE Streams framework was designed in
accordance with the patterns/architecture of System V STREAMS since
that solved the problems I was confronting at the time (see Appendix 2
in C++NPv1 for details).  Naturally, if you confront different
problems and want to generalize ACE Streams that is also a time
honored way in which things evolve.

>> Yes, thanks.  I had indeed missed this example.  It clearly
>> demonstrates that init() is the way in which a Task gets parameters
>> from the Service Configurator.  But it does not do much to shed
>> light on who calls that method when, and more importantly, how the
>> Module is/is-not involved in the Stream/Module/Task construction &
>> initialization process.

These sorts of issues are described in other places, e.g., Chapter 5
of C++NPv2 describes the ACE Service Configurator pattern and the
papers at

http://www.cs.wustl.edu/~schmidt/PDF/C++-USENIX-94.pdf
http://www.cs.wustl.edu/~schmidt/PDF/DSEJ-94.pdf

describes other aspects of the ACE Streams framework.

>> =======================
>> Steve Huston> As stated in C++NPv1 and APG, the open() method is very often
>> a
>> Steve Huston> status-value returning alternative to the constructor. That is
>> the
>> 
>> I assume here Steve means "an open() method is intended to be..." as opposed
>> to "the Task class' open() method actually is very often used as a
>> status-value returning alternative ..."

Please read Sidebar 47 in C++NPv2 and you'll see what he's saying wrt
the difference between creation and activation.

>> I would also argue that this is not how open() is used by Stream.
>> It is not used to construct objects, it is used to notify them that
>> they are about to be used, so that they may be initialized and
>> ready to run!  After all, every time I add/remove a module to a
>> Stream its tasks get open()ed by Stream.

More precisely - open() is responsible for activating a module/task.
Please see the discussion in Sidebar 47 for the discussion of why we
differentiate between creation and activation in ACE.

>> Seems more natural to think of open() in the opposite way, as a
>> method preparing an instantiated object for execution (not as an
>> alternative to a constructor).  A synonym might be Task::prepare()
>> :-)

If you'd like to think of things that way, that's fine.  But I think
Steve's approach is more consistent with how open() is used in ACE, as
you'll see when you check out Sidebar 47 in C++NPv2.

>> In that case, the way in which Module::open() is used (or in fact,
>> not used) is a bit idiosynchratic, since neither Stream nor the
>> Service_Configurator calls it in a useful way (i.e., in a way which
>> allows it to participate in the dynamic configuration mechanisms).

Right - that's not how the ACE Service Configurator framework is
intended to be used.

>> =======================
>> Steve Huston> How would you change the documentation
>> 
>> The documentation for Module::open() reads:  Create an initialized module
>> with <module_name> as its identity and <reader> and <writer> as its tasks.
>> Previously register reader or writers or closed down and deleted according
>> to the value of flags_. Should not be called from within
>> <ACE_Task::module_closed>.

That documentation is rather pithy, but then again, ACE_Module::open()
doesn't do very much either ;-)  All the hard stuff is done elsewhere,
e.g., ACE_Stream::push()/pop().

>> The documentation for Task::open() reads:  Hook called to open a Task.
>> <args> can be used to pass arbitrary information into <open>.
>> Reimplemented in ACE_NT_Service, ACE_Stream_Head<>, ACE_Stream_Tail<>,
>> ACE_Thru_Task<>, ACE_Svc_Handler<, >, and ACE_Svc_Handler<
>> ACE_PEER_STREAM_2, ACE_SYNCH_USE >.
>> 
>> A better doc string might read "Call this method in order to initialize an
>> already instantiated Task and prepare it for execution.

I like this - I've updated the documentation to say something along
these lines.

>> This method is used by ACE_Stream when an ACE_Module is added to
>> it, passing the arg parameter saved by the ACE_Module during
>> ACE_Module::open().  See Shared_Object::init() for passing
>> command-line arguments to Tasks from the Service_Configurator.
>> Modules do not directly participate in service configuration."

Hum, this seems additional information that isn't relevant for many
(most?) use-cases (since in practice ACE_Tasks are FAR more frequently
used outside the context of the ACE Streams framework).  I think it's
better to add this sort of information to ACE_Stream::push() rather
than ACE_Task since people who use it need to know this relationship
with the ACE_Tasks.  In fact, I've updated the ACE source code now so
it makes this point more clear.

>> The original doc strings imply that open() creates a Module object,
>> and their common void*arg argument implies to a learner of ACE that
>> they are related.  I.e., that these methods are "deeply" involved
>> in the initialization of Modules & Tasks.  As ACE experts it may be
>> hard for you to imagine what the (large) jumble of classes, methods
>> and interactions looks like to a newbie.  I can tell you that the
>> exact nature of initialization, preparation for execution, etc. was
>> hazy at best until I started reading the source.
>>
>> Since all documentation ever written has holes, one is always using
>> past experience and other hints to infer what's not explicitly
>> stated.  In general, the ACE documentation needs a bit more
>> explicit discussion about the interaction of methods (vs. abstract
>> object level concepts).

Right, there's no question that the documentation can be greatly
improved - thanks for the suggestions!  If you'd like to help improve
other parts of the documentation please let us know.

>> From the above text, for example, it is just too easy to infer that
>> Module::open() is called by the service configurator to pass the
>> arguments from a module line in svc.conf into the Module.

Hum, I'm not sure why you'd think this since init() is *always* the
hook used by the ACE Service Configurator framework to initalize
things.

>> Surprise surprise, Module in fact *never* gets a chance to interact
>> with those parameters.

Right, as I mentioned earlier, ACE_Module is a very simple/limited
class.

>> As I read the source I learned that the Module class is barely used
>> as much more than a struct for remembering two pointers to
>> contained Tasks and for adding/removing them to a linked list as
>> pairs.  In some examples, it was clear that Modules were to be
>> treated like invisible citizens or placeholders.

Yes, that's correct.

>> In my humble opinion, this isn't an optimally useful way to think
>> about Modules.  

Well, don't argue with me - argue with Dennis Ritchie since it's his
System V STREAMS design that is the basis for ACE Streams!!  But
seriously, I agree with you that it would be more powerful to consider
ACE_Module as a container for ACE_Tasks.  The trick is to do this in a
way that doesn't break existing stuff.

>> Also, it doesn't jive well with the implication that modules can
>> take parameters (per the service configurator's grammar amd the
>> open(,void*arg,) ), nor with the implication made by the OO overal
>> OO design.  i.e., that a Module is a meaningful abstraction that
>> fits into and has the opportunity to interact with a Stream's
>> lifecycle.

I think if you read the original paper by Dennis Ritchie on STREAMS
this stuff will make mor sense.  Check out 

http://cm.bell-labs.com/cm/cs/who/dmr/st.html

for a copy.

>> In the current code, it's not modules that take parameters, despite the
>> open(...,void *arg,...).  It's Tasks!

Yup - again that's based on System V STREAMS.

>> The service configurator skips the Module object and calls
>> Task::init() directly on the contained Tasks, and there are no
>> obvious facilities to make good use of that nice little arg
>> parameter.  I'd have to create a _make_myModule() function by hand
>> and call the Module constructor explicitly to get something useful
>> into Module::arg_.  And I can forget about parameterizing through
>> svc.conf.

I think you're trying to use ACE_Module in ways it wasn't designed to
be used.  Having said that, of course, it would be nice to generalize
ACE_Module to be more useful if we don't break stuff in the process.

>> Wouldn't it be much more consistent, and less ad-hoc, to allow the
>> service configurator to call Module::init() and let Module worry
>> about how to initialize its contained objects??  But I digress.

Perhaps, though that wasn't the design baseline.

>> Yes Module::open is called by its constructor.  But the code and
>> the documentation implies that this is useful in part because of
>> the "arg" argument.  I did not easily find a case where the Module
>> constructor is called and arg is not defaulted to Null.

Right, that's by far the common case.

>> So if I'm right, then Task::open() actually never gets a useful
>> void*arg; certainly not as part of the framework interactions.

It's there if you need it, but it isn't widely used, so the default is
NULL.

>> And, if I *am* subclassing these objects to add complex behaviors, consider:
>> 
>> * The fact that Module::open() is never called by the framework except
>> during Module construction
>> * The fact that none of the Service_Configurator macros/code allow me to
>> set/manipulate arg

I don't know why you are hung up on the arg here - it's really a
low-level hack and should rarely be needed/used!

>> Off I go to make my subclass, only to find there are no good hooks to make
>> subclassing ACE_Module a useful thing to do!
>>
>> But may I suggest an alternative?

Yes, indeed.

>> If I am designing a complex system, it is natural for me to think
>> of the Module class as a manager for the underlying Tasks.

That's definitely one way to think of things, though again, it's not
how System V STREAMS did it, which is why it isn't the way in which
ACE Streams works, yadda/yadda.

>> After all, the Module is what's instantiated and referenced in the
>> configuration file, and it is a concept that means a component of a
>> bi-directional stream.

Right.

>> Alright, so now I'm building a complex stream of out Module legos.
>> And one of my modules must modulate its behavior based on an out of
>> band condition.  E.g., it's raining now so please reduce the flow
>> of water through this stream.  Where do I put that code?  A Module
>> subclass seems natural.

Naturally, this is done via ACE_Task subclasses in the ACE Streams
framework for reasons dating back to... System V STREAMS.

>> stream dynamic WaterFlow STREAM *:IrrigationSystem() "--from Hudson --to
>> Tributary"
>> {
>> 	dynamic Valve Module *:BrassHighCapacityRainSensorAttenuator() "--level
>> 2inches"
>> }
>> 
>> Ok, off I go to create the subclass ... but woops, the ACE framework is
>> interacting with my component tasks for me without involving me except as a
>> container.  And if I wanted to allow svc.conf to parameterize the rainfall
>> amount that should cause me to modulate the flow of water, I have no way to
>> get my hands on it!

Again, if you'd like to enhance the framework so that this is possible
please go ahead and do it.  Naturally, any solutions that get
propagated back to ACE will need to be backwardly compatible.

>> Now, I can create a Task subclass that knows how to move buckets
>> and takes a rate parameter.  And I can create Module subclasses
>> that know how to sense their environment and dynamically
>> reconfigure their contained Tasks by changing that rate parameter.
>> And I can set my Modules' behavior via the service configurator.
>> And the Modules can decide which parts of the service argument
>> string gets forwarded to the underlying tasks.
>>
>> Specific code changes:
>> 
>> 
>> A grep of '[>]open' in the ace directory seems to indicate that the only
>> class that uses Task::open is Stream.

Sort of...  The ACE_Acceptor and ACE_Connector frameworks also use
open(), though it's via ACE_Svc_Handler, which is a subclass of
ACE_Task.  In general, there is LOTS of uses of ACE_Task::open() in
all sorts of other code, including The ACE ORB (TAO).

>> And it does so in order to pass in
>> the owning Module's arg.
>> 
>> I'd suggest that Module be a Service_Object, giving it an init() method for
>> use during dynamic instantiation.

I think it's possible to do this without breaking source/API-level
backwards compatibility, though it would be necessary to validate this
empirically before making any sweeping changes to ACE.

>> I'd suggest that the service configuration framework's Module_Service_Type
>> not do:
>> 
>> reader->init()
>> writer->init()
>> 
>> but instead do:
>> 
>> mod->init()

Sure, that is also probably possible.

>> Module::init() subclasses can then decide whether/which arguments get passed
>> on to the Tasks.
>> Module::init() default is to call q_pair[0]->init() and q_pair[1]->init()...
>> 
>> Module constructor & Module::open can stay as is [CASE A], although if the
>> meaning of open() is [CASE B] "you are about to run," then a different
>> status-returning initializer method should be provided so that it can be
>> used by the constructor and possibly by Module::open().
>> 
>> I'd suggest that Stream not do:
>> 
>> mod->reader ()->open()
>> mod->writer ()->open()
>> 
>> but instead it should notify the Module to open its Tasks via something
>> like:
>> 
>> mod->open() (also called by constructor!)

I think this would break existing code.

>> or
>> mod->openTasks()  (not called by constructor!)

I think this would not break existing code, so I'd recommend that
approach.

>> If Stream does mod->open() then you get Module::open() called twice
>> in rapid succession (once when Module is created and once when it
>> gets put into a Stream).  This might be a good reason to do CASE B
>> in above paragraph, so that Module construction doesn't imply the
>> Module is about to run.

Yes, indeed - we don't want to do this ;-)

>> All of this is relevant when you think of Modules are more than
>> mere containers for Tasks, but instead also as managers of how the
>> Tasks behave.  To me, this seems to fit naturally into the concept
>> of PIPE and FILTER.

I think many of your suggestions above would make a great addition to
ACE.  Since you've put a LOT of good thought into this, would you be
willing to make the changes, test them to make sure that they don't
break existing applications/tests (e.g., ACE_ROOT/tests/), and
contribute them back to us?  I think that would be very helpful!

Thanks,

        Doug




















-- 
Dr. Douglas C. Schmidt, Professor           TEL: (615) 343-8197
Electrical Engineering and Computer Science FAX: (615) 343-7440
Vanderbilt University                       WEB: www.cs.wustl.edu/~schmidt/
Nashville, TN 37203                         NET: d.schmidt@vanderbilt.edu

0
Douglas
8/13/2004 10:09:05 PM
comp.soft-sys.ace 20326 articles. 1 followers. marlow.andrew (167) is leader. Post Follow

0 Replies
920 Views

Similar Articles

[PageSpeed] 19

Reply:

Similar Artilces:

RE: [ace-bugs] Re: [ace-users] RE: Module->open()
:-) :-) :-) :-) :-) :-) :-) :-) I just want to make sure none of what's below is taken as anything but constructive--I did not edit for tone. As before. Caveat, I may be a fool. ACE rocks. A. ===================== Douglas Schmidt> I don't think you're a fool, but you haven't read the documentation or Douglas Schmidt> looked at the examples of how to program the ACE Streams framework. Actually I own two of the three ACE books and I habitually read the documentation and examples. I guess I'm just pushing the limits a bit and trying to avoid writing a whole bunch of new code. I view ACE_Stream/Module/Task as a good vehicle for a component-based design of network protocol processing that includes complex/stateful behaviors. The Streams framework has components and behaviors relevant to dynamically configuring services which consist of a set of cooperating sub-objects. I understand that the assumption in Streams is that these sub-objects are linearly (bi-directonally) associated and that they contain exactly two ACE_Tasks. But in fact this there's not much in the code that requires this to be the case, and the System V Streams / PIPE&FILTER abstraction doesn't have to be taken quite so litterally. E.g., what if I had three tasks in a module where the third task dynamically monitored the queue sizes of the other two? E.g., what if I had a Task abstraction that generated polymorphic events (...

[ace-bugs] Re: [ace-users] RE: Module->open()
Hi, >> As a follow up, it seems perhaps the intent is to have the service >> configurator call init() on the component Tasks (which are >> Shared_Objects), but to have the Stream subsequently call open() on >> those same Tasks. The only problem is that the Module is never >> open()'ed by the service configurator, so the module never gets a >> chance to initialize an "arg" to pass into the Task. Perhaps >> Module should derive from Shared_Object as well, since modules can >> be dynamically configured. etc. Please see $ACE_ROOT/examples/ASX/CCM_App/ for the canonical example of how to program the ACE Streams framework (including ACE_Module and ACE_Task) in the context of the ACE Service Configurator framework. >> I've posted in the past about problems with the service >> configuration code and I believe the maintainers have stated that a >> good cleanup is in order. I don't know what you're talking about here. >> Buyers beware. Buyers read the documentation. >> Caveat: I could be a fool. I don't think you're a fool, but you haven't read the documentation or looked at the examples of how to program the ACE Streams framework. Take care, Doug -- Dr. Douglas C. Schmidt, Professor TEL: (615) 343-8197 Electrical Engineering and Computer Science FAX: (615) 343-7440 Vanderbilt University ...

RE: [ace-bugs] Re: [ace-users] ACE & POSIX
Hey there's a thought. ;-) I like it. Kindly, Graham -----Original Message----- From: owner-ace-bugs@cse.wustl.edu [mailto:owner-ace-bugs@cse.wustl.edu] On Behalf Of Stephen Torri Sent: Monday, June 14, 2004 9:38 PM To: Douglas C. Schmidt Cc: ace-bugs@cs.wustl.edu Subject: Re: [ace-bugs] Re: [ace-users] ACE & POSIX Douglas C. Schmidt wrote: > Hi Folks, > > >>Yes, but it sure would make the ACE libraries smaller and potentially >>easier to maintain. A lot of the OS specific code would go away. ;-) > > > Ah, but there's rub! It will actually make ACE much larger and harder > to maintain since there will be many platforms/compiler that don't > support the new standard for many years, so it will be necessary to > support multiple variants! Having said that, I welcome these > enhancements since I think they will help improve the relevance of C++ > (cf Java), but it won't make ACE smaller and easier to maintain > (unfortunately)! > > Take care, > > Doug So consider it a new opportunity to develop new design patterns, write more papers and books, and become financially independent. ;) Stephen ...

[ace-bugs] Re: [ace-users] Module->open()
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. >> The Module->open() calls seem not to be used anywhere in ACE. What is Module->open()? Are you referring to ACE_Module::open()? If so, then it certainly is used in ACE in the ACE Streams framework (see Chapter 9 of C++NPv2 <www.cs.wustl.edu/~schmidt/ACE/book2> for details). >> Adding to the confusion is the fact that the service configurator >> uses the Shared_Object->init() Again, I assume you mean ACE_Shared_Object::init() right? >> call to initialize new modules (not open()). Yes, of course - that's how the service configurator works. >> If I am right and open() is not used by the ACE framework, its doc >> string should be different. It should not imply that open is >> called as part of preparing a module to begin execution. You are not correct - ACE_Modeule::open() *is* used every time an ACE_Module is created, as shown in...

Re: [ace-users] [BULK] Re: [ace-bugs] [BULK] Re: Calling ACE::init() causes exception on 20th instantiation of a
Thanks to Aleksandar Vukajlovic at finsoft! He got us a bit closer to finding this issue and also came up with some much simpler test code that reproduces the issue (see below). It seems that ACE::fini is not properly cleaning up a thread or some storage. When config.h file is modified to include more thread keys (#define ACE_DEFAULT_THREAD_KEYS 1000), the issue occurs later on. The default value for ACE_DEFAULT_THREAD_KEYS is 64, with this, ACE::init will fail after ~20 iterations, with it increased to 1000, ACE::init fails ~500 iterations. Small program that will reproduce bug without using complex MFC follows from Aleksandar. Many thanks in advance for anyone who can help debug this. - Andrew //Test code #include "ace/OS.h" #include "ace/Log_Msg.h" #ifdef _DEBUG const char* dll_name = "U:\\Temp\\TestACEInit\\DllTest\\Debug\\DllTest.dll"; #else const char* dll_name = "U:\\Temp\\TestACEInit\\DllTest\\Release\\DllTest.dll"; #endif //_DEBUG void doTest () { for (int i = 0; i < 1000; ++i) { HMODULE hm = ::LoadLibrary (dll_name); if (hm == NULL) ACE_DEBUG ((LM_ERROR, "failed to load library, iteration (%d)\n", i)); if (::FreeLibrary (hm) == FALSE) ACE_DEBUG ((LM_ERROR, "failed to free library, iteration (%d)\n", i)); } } int main (int argc, char* argv[]) { doTest (); return 0; } ////////////////////////////////// // DllTest code...

Re: [ace-bugs] RE: FW: [ace-users] ACE & POSIX
Hi Graham, >> Having spent most of my time in the murky world of real-time >> embedded systems (for the medical industry) I can tell you this. >> It is quite unlikely that the "old dodgers" (according to your >> definition I would fall into that category) would upgrade their >> version of ACE. If the current (or older) version of ACE works why >> upgrade? That's not been our experience working with scores of companies during the past decade. There are many companies who are stuck using older compiler platforms, but are quite happy to upgrade to newer versions of ACE, particularly when those versions fix important bugs, improve compile-/run-time performance, and/or add useful features. In fact, companies like OCI do a good business supporting precisely these sorts of uesrs. >> The old gnu 2.7.2 compiler that was mentioned earlier is most >> likely the compiler that is used by Windriver's IDE Tornado (which >> I use daily). Tornado 2.0.2 for Intel CPUs uses a snapshot of the >> (2.7.2) gnu compiler (Although Windriver doesn't like to admit it. >> I don't know how they get around the open source rules.). Even the >> "new" version of Tornado coming out this fall uses a newer but >> still older version of the gnu compiler. But rumor has it that the >> Diablo compiler, which has been recently only available for >> Motorola C...

RE: [ace-users] Re: ACE #2
Hi, Somewhere in your app you should run the reactor loop Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl > >> I update the ACE version to 5.4.10, but it seems have no help. > >> > >> ACE_Logging_Strategy : the -m option does not work. > >> > >> ACE VERSION: 5.4.10 > >> > >> HOST MACHINE and OPERATING SYSTEM: > >> Windows XP SP2 > >> > >> TARGET MACHINE and OPERATING SYSTEM, if different from HOST: > >> Windows XP SP2 > >> > >> THE $ACE_ROOT/ace/config.h FILE : > >> #include "ace/config-win32.h" > >> > >> THE $ACE_ROOT/include/makeinclude/platform_macros.GNU > FILE [if you > >> use a link to a platform-specific file, simply state which one > >> (unless this isn't used in this case, e.g., with > Microsoft Visual > >> C++)]: > >> Microsoft Visual C++ 6.0 sp6 > >> > >> CONTENTS OF > >> $ACE_ROOT/bin/MakeProjectCreator/config/default.features > >> (used by MPC when you generate your own makefiles): > >> There is no this file. > >> > >> AREA/CLASS/EXAMPLE AFFECTED: > >> APG\Logging\Use_Logging_Strategy.d...

RE: [ace-users] Re: ACE #2
This is a multi-part message in MIME format. ------_=_NextPart_001_01C6413F.CD2A80C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Logging_Strategy problems were fixed in 5.4.7. You should definitely upgrade. =20 Howard =20 _____ =20 From: owner-ace-users@cse.wustl.edu [mailto:owner-ace-users@cse.wustl.edu] On Behalf Of Kobi Cohen-Arazi Sent: Thursday, March 02, 2006 12:44 AM To: hileon@gmail.com Cc: ace-users@cs.wustl.edu Subject: Re: [ace-users] Re: ACE =20 Hi, We had bugs in that specific area (Limit the size using Logging_Strategy) in x.4.0. You probably seeing that same bug ... It was fixed year ago. Upgrading may help.=20 Thanks, Kobi. On 3/1/06, Douglas C. Schmidt <schmidt@cse.wustl.edu> wrote: Hi, >> I use ACE 5.4+TAO 1.4. 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=20 $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=20 "guess" what version/platform/compiler/options you've using, which is error-prone and slows down our responsiveness. Moreover, please upgrade to ACE+TAO x.4.10, which you can download...

RE: [ace-users] Re: ACE #2
Hi Folks, > Sorry about the wrong message. It does work, I did not wait enough > To roll it over. Ok, great - I'm glad to hear that it works! Thanks, Doug ...

RE: [doc_group] [devo_group] RE: [ace-users] Re: [ace-bugs] ACE_SV_Semaphore_Complex and SEM_UNDO
On Tue, 12 Aug 2003, Kobi Cohen Arazi wrote: > So are we counting on luck here ? > > Kobi. > Not really. Things change. I don't expect existing code to break anytime soon, but we will have to change as we move forward. Thus, as these issues are found, as you found this one, they should be addressed or at least recorded in a bugzilla entry. Rich ...

Re: [ace-bugs] RE: [ace-users] Linux LFS (Large File Support) and ACE
Hi, >> I guess I'm a bit confused. From what I've read on the net, it >> seems that if I define -D_FILE_OFFSET_BITS=64 (as reported by >> getconf LFS_CFLAGS on linux), and my code uses posix types >> religiously, then my code should become large-file capable "just >> like that." Based on your email, if ACE is type-safe, then it >> should magically support large files given this flag. (getconf >> LFS_LDFLAGS returns nothing on linux). >> >> Yet, you also mention adding interfaces ACE_OS and ACE_File. What >> would be the motivation of those interfaces if the above is true? >> >> I suppose the answer is "to support large files on systems that do >> not support LFS API's posixely" ? I think the main issue here is that different operating systems provide different ways to handle "large" files. For example, some operating systems have you pass special compile flags (e.g. -D_FILE_OFFSET_BITS=64) and/or use special functions (e.g., the *64() functions provided by AIX and HP/UX). As far as I know, there is no POSIX "standard" way to handle this. There's no current support in ACE for the *64() functions, which is what's provided by that *.zip file whose URL I sent you. It may be easier, however, just to try and recompile ACE and your apps using the -D_FILE_OFFSET_BITS=64 to see if that works first. If not, pleas...

[ace-bugs] Re: [ace-users] Moving to ACE? #2
Hi Roger, >> Could you please explain these kernel problems on Linux? I think there are two problems: .. There are (were) bugs in the Linux implementation of the aio_*() functions. These manifested themselves by failures of the $ACE_ROOT/tests/Proactor_Test.cpp on Linux. .. The Linux kernel implements the aio_*() functions by spawning a thread for each asynchronous request, which sort of defeats the point of asynchronous I/O! Take care, Doug -- Dr. Douglas C. Schmidt, Professor TEL: (615) 343-8197 Electrical Engineering and Computer Science FAX: (615) 343-7440 Vanderbilt University WEB: www.cs.wustl.edu/~schmidt/ Nashville, TN 37203 NET: d.schmidt@vanderbilt.edu ...

RE: [ace-bugs] Re: [ace-users] Bug? in ACE_Connector::connect_i
Steve, As I promised, I've checked it again, with a clean machine and build. The original source (without the modification) works. (But ofcourse :-) And it should be ... ACE_SOCKCALL_RETURN sets the errno using ::WSAGetLastError() ... If that isn't working - nothing will ... There was an include/lib mess on the machine where that problem was introduced to me. Thanks, Kobi. -----Original Message----- From: Kobi Cohen-Arazi [mailto:kobi-co@barak-online.net] Sent: Thursday, December 04, 2003 6:24 PM To: Steve Huston Cc: ace-users@cs.wustl.edu; ace-bugs@cs.wustl.edu Subject: [ace-bug...

Re: [ace-bugs] Re: [ace-users] Ideal Timeouts for putq() and getq() ? #2
Hi Ganesh, >> Another approach (if you don't need the ACE_Data_Block's buffer management) >> is to derive the objects from ACE_Data_Block (default constructor) and wrap >> them in ACE_Message_Block's. >> >> By doing so, the size returned by embedded data block is always 0 and >> the HWM is never reached, thus calls will never block while putq is invoked. Right, but you'll eventually run out of memory if the clients continuously send data faster than the server can process them! Flow control is your friend ;-) Take care, Doug -- Dr. Douglas C. Schmidt, Professor TEL: (615) 343-8197 Electrical Engineering and Computer Science FAX: (615) 343-7440 Vanderbilt University WEB: www.cs.wustl.edu/~schmidt/ Nashville, TN 37203 NET: d.schmidt@vanderbilt.edu ...

[ace-bugs] RE: [ace-users] RE: Making a message queue read only #2
Hi Rick, > I'm working on usage of an ACE_Task<ACE_MT_SYNCH> with a couple of > background threads processing requests in a svc() loop and wanted > some feedback on an approach I'm using for graceful shutdown. I've > read through chapter 6 of C++NPv2 and adopted some of the key > elements from that, specifically the use of a shutdown message and > waiting on the threads to finish. But I want to make sure that I > don't leave any messages on the internal queue and so have adopted > the following approach: > > When I get the shutdown message, I deactivate the queue (causing the > other threads svc() loops to exit), I reset the HWM to 0 > (effectively making the queue read-only), then reactivate the queue > and process any possible messages that may still have been on the > queue before exiting the thread that picked up the shutdown message. > > I haven't seen anything explicit in this regard (draining the queue) > in the books or examples, so I'm looking for any feedback on this > approach. > > Specifically: > - Is this reasonable? This sounds reasonable to me. Most importantly - does it work?! > - Am I misusing the flow control capabilities by doing this? Would others > understand this? Or would it better to subclass message queue and implement > some behavior that support making a queue read-only and would return a > specific error wh...

Re: [ace-bugs] Re: [ace-users] Regex...
Hi Doug: > >> ACE is already too bloated, I do not want it to become yet > >> another library that does one thing very well (networking, > >> concurrency in its case) while doing many others badly. > > Unfortunately, you've not been privy to MANY discussions about how to > avoid bloating ACE with the regex stuff, which will ultimately be > auto-confiscated in if users want these capabilities - otherwise, they > won't be affected. Will/Don, if you guys have copies of the many > emails you guys traded on this topic could you please forward them to > Carlos? I don't think I have any of them handy, but Will probably does. Carlos, I'm certainly against bloating ACE. The only part I've played in this is helping Will with the preprocessor logic necessary for including alternate versions of regex, which could include boost btw, on platforms that don't provide it natively. He's added the standard regex funtions to the ACE_OS namespace which call the underlying implementation. PCRE isn't really POSIX compatible, please see the man page for details, so Will has looked into other libraries as well. The idea is to avoid lots of emulation and code bloat that we'd have to maintain. This is no different than any other function in ACE_OS. I don't know anything about the ACE_Regex class and will probably never use it since the regular regex functional...

RE: [ace-users] Re: I cannot build ACE #2
Hi Steve > Actually, it's because the GNUmakefiles generated for the ACE release > don't include the 'ssl' feature. You have to regenerate the > GNUmakefiles with ssl enabled. The GNUmakefiles do have SSL support as part of the distribution (not the other project types). For the GNU make it should work to add ssl=1 to the platform_macros.GNU file and then build it. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl ...

RE: [ace-users] Re: I cannot build ACE #2
Hi, If you need ssl support you add ssl=1 to your platform_macros.GNU file and install ssl, see the ACE-INSTALL.html document for more info. If you don't need these optional libraries, just ignore the warnings. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl > -----Original Message----- > From: Ji Soo [mailto:mycorba@gmail.com] > Sent: maandag 20 maart 2006 2:16 > To: jwillemsen@remedy.nl > Cc: Steve Huston; ace-users@cs.wustl.edu > Subject: Re: [ace-users] Re: I cannot build ACE > > Hello, > > The complete "make" output: > > ...... > ...... > rm -f libACE.so > ln -s libACE.so.5.5.0 libACE.so > chmod a+rx libACE.so.5.5.0 > make[1]: Leaving directory `/opt/ACE_wrappers/ace' > make[1]: Entering directory `/opt/ACE_wrappers/ace' > This project will not be built due to one of the following > missing features: > x11 gl fl > GNUmakefile: /opt/ACE_wrappers/ace/GNUmakefile.ACE_FlReactor > MAKEFLAGS=w > > make[1]: Leaving directory `/opt/ACE_wrappers/ace' > make[1]: Entering directory `/opt/ACE_wrappers/ace' > This project will not be built due to one of the following > missing features: > qt > > GNUmakefile: /opt/ACE_wrappers/ace/GNUmakefile.ACE_QtReactor > MAKEFLAGS=w > > make[1]: Leaving directory `/opt/AC...

RE: [ace-users] Re: I cannot build ACE #2
Actually, it's because the GNUmakefiles generated for the ACE release don't include the 'ssl' feature. You have to regenerate the GNUmakefiles with ssl enabled. I added this to the Riverace support customers' FAQ section recently. I'll get an external FAQ section set up shortly. -Steve -- Steve Huston, Riverace Corporation Helping you succeed with ACE See http://www.riverace.com/support.htm > -----Original Message----- > From: owner-ace-users@cse.wustl.edu > [mailto:owner-ace-users@cse.wustl.edu] On Behalf Of Johnny Willemsen > Sent: Friday, March 17, 2006 4:04 AM > To: 'Ji Soo'; ace-users@cs.wustl.edu > Subject: RE: [ace-users] Re: I cannot build ACE > > > Hi, > > This is not a problem, you don't have ssl installed, so it is not just > build. The ACE lib itself is build. > > Regards, > > Johnny Willemsen > Remedy IT > Postbus 101 > 2650 AC Berkel en Rodenrijs > The Netherlands > www.theaceorb.nl / www.remedy.nl > > > -----Original Messag...

RE: [ace-users] Re: ACE
Hi, When ACE 5.4 was released the MinGW port wasn't really up to date. Upgrade to the latest beta, that will work. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl > -----Original Message----- > From: owner-ace-users@cse.wustl.edu > [mailto:owner-ace-users@cse.wustl.edu] On Behalf Of Douglas C. Schmidt > Sent: woensdag 12 oktober 2005 19:11 > To: silviu_andrica@yahoo.com > Cc: ace-users@cs.wustl.edu > Subject: [ace-users] Re: ACE > > > Hi Silviu, > > > i'm sorry fot bothering you and i know that you get this kind of > > emails all the time, > > Thanks very much for your email. Please make sure to send all > questions related to TAO or ACE to the ACE mailing list or ACE+TAO > newsgroup, rather than to me directly since I travel frequently and > often don't have ready access to email. See > > http://www.cs.wustl.edu/~schmidt/ACE-mail.html > > for more info on how to access these resources. > > > but i have a problem > > with compiling ACE 5.4. I'm trying to compile it using > > MinGW on Windows XP (SP2). > > 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...

[ace-bugs] Re: [ace-users] ACE
Hi, Thanks for using the PRF. >> ACE VERSION: 5.4.1 >> >> HP Server and HP-UX 11.1 >> >> aCC: HP ANSI C++ B3910B A.03.37 >> >> CONTENTS OF $ACE_ROOT/ace/config.h : config-hpux-11.00.h >> >> CONTENTS OF $ACE_ROOT/include/makeinclude/platform_macros.GNU : >> platorm_hpux_aCC.GNU >> >> AREA/CLASS/EXAMPLE AFFECTED: >> >> $ACE_ROOT/ace - Compiled successfully but >> >> $ACE_ROOT/ - failed to compile as shown below >> >> Installing gperf -> /home/umitd/Projects/Trophy/lib/ACE_wrappers/bin >> Installing gperf -> /home/umitd/Projects/Trophy/lib/ACE_wrappers/bin >> gmake[6]: Leaving directory >> `/home/umitd/Projects/Trophy/lib/ACE_wrappers/apps/g >> perf/src' >> cd tests && gmake -f Makefile all >> gmake[6]: Entering directory >> `/home/umitd/Projects/Trophy/lib/ACE_wrappers/apps/ >> gperf/tests' >> >> Makefile: >> /home/umitd/Projects/Trophy/lib/ACE_wrappers/apps/gperf/tests/Makefile >> >> aCC -AA +W930 +W302 +DAportable -g -DACE_HAS_THREADS -D_REENTRANT >> -D_RWSTD_MULTI >> _THREAD -D_POSIX_C_SOURCE=199506L -D_HPUX_SOURCE -DHPUX_VERS=1111 >> -DACE_LACKS_PR >> AGMA_ONCE -I/home/umitd/Projects/Trophy/lib/ACE_wrappers >> -DACE_HAS_EXCEPTIONS >> -D__ACE_INLINE__ -c -o .obj/test.o te...

[ace-bugs] Re: [ace-users] ACE & POSIX #2
Hi Folks, > Yes, but it sure would make the ACE libraries smaller and > potentially easier to maintain. A lot of the OS specific code would > go away. ;-) Ah, but there's rub! It will actually make ACE much larger and harder to maintain since there will be many platforms/compiler that don't support the new standard for many years, so it will be necessary to support multiple variants! Having said that, I welcome these enhancements since I think they will help improve the relevance of C++ (cf Java), but it won't make ACE smaller and easier to maintain (unfortunately)! Take care, Doug -- Dr. Douglas C. Schmidt, Professor TEL: (615) 343-8197 Electrical Engineering and Computer Science FAX: (615) 343-7440 Vanderbilt University WEB: www.cs.wustl.edu/~schmidt/ Nashville, TN 37203 NET: d.schmidt@vanderbilt.edu Douglas C. Schmidt wrote: > Hi Folks, > > >>Yes, but it sure would make the ACE libraries smaller and >>potentially easier to maintain. A lot of the OS specific code would >>go away. ;-) > > > Ah, but there's rub! It will actually make ACE much larger and harder > to maintain since there will be many platforms/compiler that don't > support the new standard for many years, so it will be necessary to > support multiple variants! Having said that, I welcome these > enhancements since I th...

[ace-bugs] RE: [ace-users] ACE & POSIX #2
Hmm...I guess that's if you wanted to support multiple variants. Personally, I would freeze development of the current version of ACE (if the additions to C++ were made) and let the old dodgers play with their old antiquated compilers and start a new smaller version of ACE using the new C++ additions. Maybe that would help create a demand for compliant compilers and/or even motivate the old dodgers to update their compilers? That way the 'rub' goes away, correct? Kindly, Graham -----Original Message----- From: Douglas C. Schmidt [mailto:schmidt@cs.wustl.edu] Sent: Monday, June 14, 2004 9:04 PM To: ace-bugs@cs.wustl.edu; greitz1@charter.net Subject: Re: [ace-users] ACE & POSIX Hi Folks, > Yes, but it sure would make the ACE libraries smaller and potentially > easier to maintain. A lot of the OS specific code would go away. ;-) Ah, but there's rub! It will actually make ACE much larger and harder to maintain since there will be many platforms/compiler that don't support the new standard for many years, so it will be necessary to support multiple variants! Having said that, I welcome these enhancements since I think they will help improve the relevance of C++ (cf Java), but it won't make ACE smaller and easier to maintain (unfortunately)! Take care, Doug -- Dr. Douglas C. Schmidt, Professor TEL: (615) 343-8197 Electrical Engineering and Computer Science FAX: (615) 343-7440 ...

[ace-bugs] Re: [ace-users] How to Use IPv6 in ACE? #2
Please stop reposting this question. Bala and I have already answered it the past several days. Check out http://groups.yahoo.com/group/ace-bugs/message/4421 for my answer. Thanks, Doug >> ACE VERSION: 5.4.1 >> >> HOST MACHINE and OPERATING SYSTEM: >> SUN Solaris 8 >> >> TARGET MACHINE and OPERATING SYSTEM, if different from HOST: >> COMPILER NAME AND VERSION (AND PATCHLEVEL): >> SUN Forte6 C++ UP1 >> >> CONTENTS OF $ACE_ROOT/ace/config.h [if you use a link to a platform- >> specific file, simply state which one]: >> config-sunos5.8.h >> >> CONTENTS OF $ACE_ROOT/include/makeinclude/platform_macros.GNU (unless >> this isn't used in this case, e.g., with Microsoft Visual C++): >> platform_sunos5_sunc++.GNU >> >> AREA/CLASS/EXAMPLE AFFECTED: >> NO >> >> DOES THE PROBLEM AFFECT: >> COMPILATION? >> NO >> LINKING? >> NO >> EXECUTION? >> NO >> OTHER (please specify)? >> NO >> >> SYNOPSIS: >> I want to know how to use IPv6 in ACE-TAO, and where i can find the documents and examples. >> >> Thanks! >> ...

Web resources about - Re: [ace-bugs] Re: [ace-users] RE: Module->open() #2 - comp.soft-sys.ace

Resources last updated: 3/5/2016 7:13:07 PM