<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.6000.16544" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>Hi 
Bogdan,</FONT></SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>Thanks 
for looking into this. Your concern about msg_off_ seems valid, though I didn't 
track down why it's like that. Your approach to solve the allocation problems 
seems to be good.</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>For 
docs on how to work with the ACE team you can hunt around <A 
href="http://www.cs.wustl.edu/~schmidt/ACE.html">http://www.cs.wustl.edu/~schmidt/ACE.html</A>.</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>When 
you have fixes, you can do one of two things:</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>1. 
Create a Bugzilla entry for the problem and attach your patches (unified diff is 
best) to the entry. This is the safest way to make sure it doesn't get 
lost.</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>2. 
Send the diffs to the ace-users list and ask for someone to integrate. This can 
work for very small issues, but this Log_Msg issue is not going to be that 
small.</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>Be 
patient (which you have been all along!) since whomever picks up your fixes to 
integrate them will implicitly take responsibility for any errors that show up 
on the scoreboard (not many people have access to the 50 or so platform 
combinations to test first, so it's not uncommon for a problem to show up). If 
people don't have much free time, they can be a bit hesitant to take 
responsibility for fixing any resultant problems. This particular ACE_Log_Msg 
fix will be more desireable to fix than usual because of the performance 
implications, but still, someone has to take responsibility for 
it.</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff 
size=2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff 
size=2>-Steve</FONT></SPAN></DIV><!-- Converted from text/plain format -->
<P><FONT size=2>--<BR>Steve Huston, Riverace Corporation<BR>Want to take ACE 
training on YOUR schedule?<BR>See <A 
href="http://www.riverace.com/training.htm">http://www.riverace.com/training.htm</A><BR></FONT></P>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Bogdan Graur 
  [mailto:bgraur@gmail.com] <BR><B>Sent:</B> Wednesday, November 28, 2007 3:26 
  PM<BR><B>To:</B> Steve Huston<BR><B>Cc:</B> 'Douglas C. Schmidt'; 
  ace-users@cse.wustl.edu<BR><B>Subject:</B> Re: [ace-users] [usage question] 
  ACE_Log_Msg / ACE_Log_Record - no allocator<BR><BR></FONT></DIV>Hello 
  all,<BR><BR>Thanks Steve for your answer!<BR>I am analyzing now the code in 
  order to do the fix and found that ACE_Log_Msg::msg_off_ member is declared 
  static. I do not think this is a good idea considering that ACE_Log_Msg class 
  is used from different threads (it is used unprotected in ACE_Log_Msg::log() 
  method) There is also some confusion about it in the code: it is used some 
  times 'like' a non-static member (this-&gt;msg_off_) and some times 'like' a 
  static one (ACE_Log_Msg::msg_off_).<BR><BR>1. Considering that ACE_Log_Msg is 
  kept in TSS I think it is OK to make member 'msg_off_'&nbsp; non-static.<BR>2. 
  Proposed fix for the every-time alloc/free (general idea):<BR><BR>a) use an 
  ACE_Log_Record* instead of ACE_TCHAR* to store the log line;<BR><BR>b) declare 
  a new constructor for the ACE_Log_Record that takes as input the size to 
  allocate for the inner buffer (currently all ACE_Log_Record ctors allocate as 
  many bytes as ACE_Log_Msg needs but we shouldn't hard code this dependency 
  between Log_Msg and Log_Record, a future change of either of one will lead to 
  the change of the other one);<BR><BR>c) allocate the Log_Record once (in the 
  ctor) and delete once (in destructor)<BR><BR>Can someone point me to a page 
  describing the process to follow when posting a fix?<BR><BR>Best 
  regards,<BR>Bogdan<BR><BR><BR>Steve Huston wrote: 
  <BLOCKQUOTE cite=mid011301c8313d$11871290$6601a8c0@hope type="cite"><PRE wrap="">Hi Bogdan,

  </PRE>
    <BLOCKQUOTE type="cite"><PRE wrap="">First I'd like to thank you for your prompt reply!
Second, I'd like to apologize for not using the the PRF (I 
thought it is 
not necessary as it was a usage question). Please find it at 
the end of my e-mail.
    </PRE></BLOCKQUOTE><PRE wrap=""><!---->
Thanks!

  </PRE>
    <BLOCKQUOTE type="cite"><PRE wrap="">I know now that each thread has its own ACE_Log_Msg instance kept in
    </PRE></BLOCKQUOTE><PRE wrap=""><!---->
  </PRE>
    <BLOCKQUOTE type="cite"><PRE wrap="">TSS. Thanks for pointing this out!

But, inside the method:
    </PRE>
      <BLOCKQUOTE type="cite"><PRE wrap="">ssize_t
ACE_Log_Msg::log (const ACE_TCHAR *format_str,
                  ACE_Log_Priority log_priority,
                  va_list argp)
      </PRE></BLOCKQUOTE><PRE wrap="">an ACE_Log_Record is instantiated on the stack for which the 
constructor 
used allocates 'another' 4 KB of data. The ACE_Log_Msg 
internal buffer 
is afterwards copied ( ACE_OS::strcpy) in the internal buffer of 
ACE_Log_Record.
    </PRE></BLOCKQUOTE><PRE wrap=""><!---->
Right... The ACE_Log_Record here used to have it's data as a member
array, and so was allocated off the stack. This was changed, from what
I can see, at:

Tue Mar 28 21:30:01 UTC 2006  jiang,shanshan
<A class=moz-txt-link-rfc2396E href="mailto:shanshan.jiang@vanderbilt.edu">&lt;shanshan.jiang@vanderbilt.edu&gt;</A>

        * ace/Log_Msg.{h,cpp}
        * ace/Log_Record.{cpp,h,inl}:
          Updated these files to solve the stack overflow problem in
ACE_Log_Msg
          and ACE_Log_Record. Moves buffers that can be large in stack
in malloced
          memory.
          Thanks to qwerty &lt;qwerty0987654321 at mail dot ru&gt; for
motivating and
          suggesting the fix to this problem.

  </PRE>
    <BLOCKQUOTE type="cite"><PRE wrap="">I made a simple test program, ran 'gdb' on it and found that 
each time 
this function is invoked, the ACE_Log_Record's constructor 
gets called 
and its underlying data is allocated at a different address 
(to try to 
rule out some overloaded 'operator new' I couldn't identify).

Please tell me if there is something I missed. Thank you!
    </PRE></BLOCKQUOTE><PRE wrap=""><!---->
Nope, you got it right, but the above work to remove the MAXLOGMSGLEN
size restriction could have been done much better to avoid the
every-time alloc/free. I believe this can be done in a much more
efficient manner. One possible idea is to replace the msg_ array in
ACE_Log_Msg with a ACE_Log_Record, but I haven't traced all the
possibilities out to see if this is a good solution. If you can work
out the details of this, that would be great. If you don't have
time/energy to do this, please record this info in Bugzilla or
consider partnering with someone who can analyze the situation and
develop a good fix for it.

Thanks very much for raising this and analyzing the source of the
excessive memory allocations.

Best regards,
-Steve

--
Steve Huston, Riverace Corporation
Want to take ACE training on YOUR schedule?
See <A class=moz-txt-link-freetext href="http://www.riverace.com/training.htm">http://www.riverace.com/training.htm</A>

  </PRE>
    <BLOCKQUOTE type="cite">
      <BLOCKQUOTE type="cite"><PRE wrap="">  
      </PRE>
        <BLOCKQUOTE type="cite"><PRE wrap="">On my understanding each time you log something using ACE_Log_Msg
        </PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=""><!---->
  </PRE>
    <BLOCKQUOTE type="cite">
      <BLOCKQUOTE type="cite">
        <BLOCKQUOTE type="cite"><PRE wrap="">another ACE_Log_Record is created which in turn creates 
        </PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap="">its underlying 
    </PRE>
      <BLOCKQUOTE type="cite">
        <BLOCKQUOTE type="cite"><PRE wrap="">data (4 KB) on the heap. This can happen very often and may have
        </PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=""><!---->a 
  </PRE>
    <BLOCKQUOTE type="cite">
      <BLOCKQUOTE type="cite">
        <BLOCKQUOTE type="cite"><PRE wrap="">negative impact on the overall performance of the application.
    
        </PRE></BLOCKQUOTE><PRE wrap="">No, that's incorrect.  the 4 KB of data is allocated using
thread-specific storage (see the discuss in the POSA2 book at
<A class=moz-txt-link-abbreviated href="http://www.cs.wustl.edu/~schmidt/POSA/POSA2/">www.cs.wustl.edu/~schmidt/POSA/POSA2/</A>), so the 4 KB is 
      </PRE></BLOCKQUOTE><PRE wrap="">allocated only
    </PRE>
      <BLOCKQUOTE type="cite"><PRE wrap="">once for each thread.

  
      </PRE>
        <BLOCKQUOTE type="cite"><PRE wrap="">Is there a way to control the allocation of ACE_Log_Record 
        </PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap="">data without 
    </PRE>
      <BLOCKQUOTE type="cite">
        <BLOCKQUOTE type="cite"><PRE wrap="">overloading the global new operator?
    
        </PRE></BLOCKQUOTE><PRE wrap="">No, but this shouldn't be necessary, as per the discussion above.

Thanks,

Doug
  
      </PRE></BLOCKQUOTE><PRE wrap="">_______________________________________________
ace-users mailing list
<A class=moz-txt-link-abbreviated href="mailto:ace-users@mail.cse.wustl.edu">ace-users@mail.cse.wustl.edu</A>
<A class=moz-txt-link-freetext href="http://mail.cse.wustl.edu/mailman/listinfo/ace-users">http://mail.cse.wustl.edu/mailman/listinfo/ace-users</A>

    </PRE></BLOCKQUOTE><PRE wrap=""><!---->


  </PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>