Hi Christian,

>> Please, I need explanation about ACE Task and ACE ThreadManager,
>>
>> ACE VERSION: 5.2

Wow, that's a REALLY old version of ACE.  I recommend that you upgrade
to ACE+TAO x.4.7, which you can download from

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

under the heading "latest beta kit".

>> PC Pentium 4  3.2Ghz - Windows XP Pro
>> Visual C++ 6.0 sp6
>>
>> A little example to explain my problem :
>>
>> class Task : public ACE_Task_Base
>> {
>>   ...
>>   int open (void *args=0)
>>   {
>>     return activate ();
>>   }
>>   ....
>>   int svc (void)
>>   {
>>     // INIT : create apps window
>>     //********************************
>>     WNDCLASS wndclass;
>>     HINSTANCE hInst;
>>     hInst = NULL;
>>     // Register display window class
>>     ...
>>     ::RegisterClass (&wndclass) ;
>>     ...
>>     m_hWndMain = ::CreateWindow ("name", str, WS_OVERLAPPEDWINDOW,
>>     atx, aty, vsize, hsize, NULL, NULL, hInst, NULL);
>>     ....
>>
>>     // LOOP
>>     //*********
>>     while ( ) {
>>       ...
>>       if (::GetMessage( &msg, NULL, 0, 0 )) <= 0) {
>>         return -1;
>>       }
>>       ...
>>     };
>>   ...
>>   return 0;
>> }
>> ...
>> }
>>
>> In fact, if I take out the Init part of the svc () method
>> and I put in the init method (for exemple in open () method ),
>> the thread doesn't work !
>>
>> Someone could tell me why ???

I think Windows stores the windows information in thread-specific
storage, so you need to make sure that the thread you use t initialize
the window is the same one you use to process of messages.

Take care,

         Doug
--
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Institute for Software Integrated Systems    WEB:
www.dre.vanderbilt.edu/~schmidt
Vanderbilt University, Nashville TN, 37203   NET: d.schmidt@...

Hi Erik,

>> Thanks much Doug (been a long time since Oopsla late 80's, early 90's).

Right!  I'll actually be at OOPSLA again this year giving a tutorial
on POSA2.

>> Got the book sright here and am working through them.

Cool  -please see Chapter 4 of C++NPv1 for info on the ACE_InputCDR
and ACE_OutputCDR classes.  There are examples of writing this stuff
to a file in that chapter.  There's an example of reading this stuff
from a file in Chapter 9 of C++NPv2.

Take care,

         Doug
--
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Institute for Software Integrated Systems    WEB:
www.dre.vanderbilt.edu/~schmidt
Vanderbilt University, Nashville TN, 37203   NET: d.schmidt@...

Hi Sandeep,

>> OS: RH EL (AS 3.0)
>> Hardware:
>> [root@CISCART27 sdi]# uname -a
>> Linux CISCART27 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17
>> 17:52:23 EDT 2005 i686 i686 i386 GNU/Linux
>> ACE lib version: 5.3.5

Wow, you are using a VERY old version of ACE.  I recommend that you
upgrade to ACE+TAO x.4.7, which you can download from

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

under the heading "latest beta kit".  Things have changed quite a bit
since then, so I suspect this memory leak has been fixed.  Please see

http://www.cs.wustl.edu/~schmidt/ACE_wrapers/ace/OS_NS_stdio.inl

to see the latest code.

Thanks,

         Doug

>> We are using ACE_File_Lock in our application as
>> below.
>> ACE_File_Lock checkLock(LockFile, RDONLY,0,0);
>>
>> if (checkLock.tryacquire() !=3D -1) {
>> Printf("tryacquir failed");
>> return false;
>> }
>>
>> Here appl1Lock is actually created by some other
>> application & we want to check if that file is present
>> (which means that app is running).
>>
>> The application is working fine. But in some cases the
>> LockFile may not be actaully be there & hence we see
>> error like "ACE_File_LOck::ACE_File_Lock <name of
>> LockFile> no such file or directory", which is also
>> ok.
>>
>> But, when the application is run with valgrind(memory
>> leak checking tool), it reports that memory allocated
>> with strdup() in the constructor ACE_File_Lock is not
>> being freed for some cases.
>>
>> I looked at the ACE code. Though I did not look at it
>> thoroughly, I felt in our case memory allocated using
>> strdup in ACE_OS::flock_init() in
>> ACE_File_Lock()::open() is not being freed in
>> ACE_OS::flock_destory().
>>
>> >From OS.i file
>> ----------------------------------------------
>> #if defined (CHORUS)
>> // Are we the owner?
>> if (lock->process_lock_ && lock->lockname_ !=3D 0)
>> {
>> // Only destroy the lock if we're the owner
>> ACE_OS::mutex_destroy (lock->process_lock_);
>> ACE_OS::munmap (lock->process_lock_,
>> sizeof (ACE_mutex_t));
>> if (unlink_file)
>> ACE_OS::shm_unlink (lock->lockname_);
>> ACE_OS::free (ACE_static_cast (void *,
>>
>> ACE_const_cast (ACE_TCHAR *,
>>
>> lock->lockname_)));
>> }
>> else if (lock->process_lock_)
>> // Just unmap the memory.
>> ACE_OS::munmap (lock->process_lock_,
>> sizeof (ACE_mutex_t));
>> -----------------------------------------------
>>
>> I think in our case since we are not the owner of lock
>> file, lock->process_lock_ is not initialized and hence
>> memory allocated to lock->lockname is not freed.
>>
>> Please let me know if this is true.
>> Forgive me if I am wrong & explain how it works.

--
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Institute for Software Integrated Systems    WEB:
www.dre.vanderbilt.edu/~schmidt
Vanderbilt University, Nashville TN, 37203   NET: d.schmidt@...

Hi Doug,

On Tue, 04 Oct 2005 16:45:02 -0500, Douglas C. Schmidt wrote:
> Hi Folks,
>
>         On UNIX you can remove a file that's been open()'d be another
> process and the OS will let you do this and will actually delete the
> file when the final handle is closed.  Is there some way to do this on
> Windows, as well?

If all the processs which have an open handle on the file, had opened the
file by passing FILE_SHARE_DELETE to CreateFile(), then a new process can
open the file by passing FILE_FLAG_DELETE_ON_CLOSE to CreateFile() when it
opens the same file, and Windows will delete the file all the open handles
are closed.

-kitty.

--
Krishnakumar B <kitty at dre dot vanderbilt dot edu>
Institute for Software Integrated Systems, Dept. of EECS, Vanderbilt University

Hi Boris,

I appreciate your patience, sorry for the late
response (both of my kids and myself caught some bug
this week :( ).

I ran the receiver example program in ddd/gdb several
times. As in previous attempts, the sender program
runs  very quickly to completion, and the receiver
lags behind until it stalls/hangs with the CPU usage
pegged. My DDD source window shows that the CPU
intensive thread is hanging in the following method:
-------
template <class EXT_ID, class INT_ID, class HASH_KEY,
class COMPARE_KEYS, class ACE_LOCK> ACE_INLINE int
ACE_Hash_Map_Manager_Ex<EXT_ID, INT_ID, HASH_KEY,
COMPARE_KEYS, ACE_LOCK>::equal (const EXT_ID &id1,

                            const EXT_ID &id2)
{
   return this->compare_keys_ (id1, id2);
}
-------

Here is the stack output when I use export
LD_ASSUME_KERNEL=2.4.1 to set LWP/Linux threads. After
the sender completed and the receiver was pegging the
CPU, I did an interrupt in DDD. Also, I'm really not
sure why there are 5 threads here instead of 4--but
that is consistent when I switch to Linux threads.
Note that in this trace, Process PID 4249 is taking
almost all of the CPU:

0xb738b916 in nanosleep () from
/lib/i686/libpthread.so.0
(gdb) bt
#0  0xb738b916 in nanosleep () from
/lib/i686/libpthread.so.0
#1  0x00000000 in ?? ()
(gdb) thread 4
[Switching to thread 4 (Thread 32771 (LWP 4248))]#0
0xb738b916 in nanosleep () from
/lib/i686/libpthread.so.0
(gdb) thread 4
[Switching to thread 4 (Thread 32771 (LWP 4248))]#0
0xb738b916 in nanosleep () from
/lib/i686/libpthread.so.0
(gdb) thread 5
[Switching to thread 5 (Thread 49156 (LWP 4249))]#0
0xb75cb91a in ACE_Hash_Map_Manager_Ex<unsigned long
long, ACE_RMCast::Acknowledge::Descr,
ACE_Hash<unsigned long long>, ACE_Equal_To<unsigned
long long>, ACE_Null_Mutex>::equal (this=0xb0d8104,
id1=@0xb87ea80, id2=@0xb6d51cdc) at
Hash_Map_Manager_T.inl:80
(gdb) thread 5
[Switching to thread 5 (Thread 49156 (LWP 4249))]#0
0xb75cb91a in ACE_Hash_Map_Manager_Ex<unsigned long
long, ACE_RMCast::Acknowledge::Descr,
ACE_Hash<unsigned long long>, ACE_Equal_To<unsigned
long long>, ACE_Null_Mutex>::equal (this=0xb0d8104,
id1=@0xb87ea80, id2=@0xb6d51cdc) at
Hash_Map_Manager_T.inl:80
(gdb) bt
#0  0xb75cb91a in ACE_Hash_Map_Manager_Ex<unsigned
long long, ACE_RMCast::Acknowledge::Descr,
ACE_Hash<unsigned long long>, ACE_Equal_To<unsigned
long long>, ACE_Null_Mutex>::equal (this=0xb0d8104,
id1=@0xb87ea80, id2=@0xb6d51cdc) at
Hash_Map_Manager_T.inl:80
#1  0xb75caafa in ACE_Hash_Map_Manager_Ex<unsigned
long long, ACE_RMCast::Acknowledge::Descr,
ACE_Hash<unsigned long long>, ACE_Equal_To<unsigned
long long>, ACE_Null_Mutex>::shared_find
(this=0xb0d8104, ext_id=@0xb6d51cdc,
entry=@0xb6d51c04, loc=@0xb6d51c00) at
Hash_Map_Manager_T.cpp:304
#2  0xb75c9c68 in ACE_Hash_Map_Manager_Ex<unsigned
long long, ACE_RMCast::Acknowledge::Descr,
ACE_Hash<unsigned long long>, ACE_Equal_To<unsigned
long long>, ACE_Null_Mutex>::find_i (this=0xb0d8104,
ext_id=@0xb6d51cdc) at Hash_Map_Manager_T.inl:197
#3  0xb75c8657 in ACE_Hash_Map_Manager_Ex<unsigned
long long, ACE_RMCast::Acknowledge::Descr,
ACE_Hash<unsigned long long>, ACE_Equal_To<unsigned
long long>, ACE_Null_Mutex>::find (this=0xb0d8104,
ext_id=@0xb6d51cdc) at Hash_Map_Manager_T.inl:222
#4  0xb75c77f4 in ACE_RMCast::Acknowledge::track_queue
(this=0x8064df8, addr=@0xb0d80e8, q=@0xb0d8104,
msgs=@0xb6d51dc4) at Acknowledge.cpp:229
#5  0xb75c6fce in ACE_RMCast::Acknowledge::track
(this=0x8064df8) at Acknowledge.cpp:104
#6  0xb75c82c7 in ACE_RMCast::Acknowledge::track_thunk
(obj=0x8064df8) at Acknowledge.cpp:384
#7  0xb754d56d in ACE_Thread_Adapter::invoke_i
(this=0xb085490) at Thread_Adapter.cpp:149
#8  0xb754d4b0 in ACE_Thread_Adapter::invoke
(this=0xb085490) at Thread_Adapter.cpp:93
#9  0xb74cd3c2 in ace_thread_adapter (args=0xb085490)
at Base_Thread_Adapter.cpp:131
#10 0xb7385e21 in pthread_start_thread () from
/lib/i686/libpthread.so.0
#11 0xb7385fb5 in pthread_start_thread_event () from
/lib/i686/libpthread.so.0
#12 0xb723108a in clone () from /lib/i686/libc.so.6
(gdb) thread 4
[Switching to thread 4 (Thread 32771 (LWP 4248))]#0
0xb738b916 in nanosleep () from
/lib/i686/libpthread.so.0
(gdb) thread 4
[Switching to thread 4 (Thread 32771 (LWP 4248))]#0
0xb738b916 in nanosleep () from
/lib/i686/libpthread.so.0
(gdb) bt
#0  0xb738b916 in nanosleep () from
/lib/i686/libpthread.so.0
#1  0x00000000 in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 16386 (LWP 4247))]#0
0xb722a5f1 in select () from /lib/i686/libc.so.6
(gdb) thread 3
[Switching to thread 3 (Thread 16386 (LWP 4247))]#0
0xb722a5f1 in select () from /lib/i686/libc.so.6
(gdb) bt
#0  0xb722a5f1 in select () from /lib/i686/libc.so.6
#1  0xb75a7920 in __JCR_LIST__ () from
/opt/ACE_wrappers/ace/libACE.so.5.4.7
#2  0xb738f5d0 in __pthread_last_event () from
/lib/i686/libpthread.so.0
#3  0x0b087a00 in ?? ()
#4  0x00000000 in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 32769 (LWP 4246))]#0
0xb722838a in poll () from /lib/i686/libc.so.6
(gdb) bt
#0  0xb722838a in poll () from /lib/i686/libc.so.6
#1  0xb7384d5e in __pthread_manager () from
/lib/i686/libpthread.so.0
#2  0xb738502a in __pthread_manager_event () from
/lib/i686/libpthread.so.0
#3  0xb723108a in clone () from /lib/i686/libc.so.6
(gdb) thread 1
[Switching to thread 1 (Thread 16384 (LWP 4243))]#0
0xb7388074 in __pthread_sigsuspend () from
/lib/i686/libpthread.so.0
(gdb) bt
#0  0xb7388074 in __pthread_sigsuspend () from
/lib/i686/libpthread.so.0
#1  0xb7387a28 in __pthread_wait_for_restart_signal ()
from /lib/i686/libpthread.so.0
#2  0xb738407b in pthread_cond_wait@GLIBC_2.0 () from
/lib/i686/libpthread.so.0
#3  0xb75cc00a in cond_wait (cv=0x804fcf8,
external_mutex=0x804fcdc) at OS_NS_Thread.inl:390
#4  0xb75cb26d in
ACE_Condition<ACE_Thread_Mutex>::wait (this=0x804fcf8)
at Condition_T.cpp:158
#5  0xb75ddaa4 in ACE_RMCast::Socket_Impl::size_
(this=0x804fcb0, timeout=0x0) at Socket.cpp:239
#6  0xb75de236 in ACE_RMCast::Socket::size
(this=0xbffff080) at Socket.cpp:357
#7  0x08049a7f in main (argc=2, argv=0xbffff114) at
Receiver.cpp:75
(gdb)

-------------------

Here, in this stack output, I am using the default
NPTL threads. As before, I am allowing the sender
program to run to completion, and then while receiver
is pegging the CPU, I do a DDD interrupt and dump the
trace of each of the 4 threads. If I use 'top' to show
threads, the thread that is performing ACE_Hash_Map
equal() is the culprit (same as for Linux threads
test).

0xb73c71fb in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/tls/libpthread.so.0
(gdb) bt
#0  0xb73c71fb in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/tls/libpthread.so.0
#1  0xb75cc00a in cond_wait (cv=0x804f520,
external_mutex=0x804f504) at OS_NS_Thread.inl:390
#2  0xb75cb26d in
ACE_Condition<ACE_Thread_Mutex>::wait (this=0x804f520)
at Condition_T.cpp:158
#3  0xb75ddaa4 in ACE_RMCast::Socket_Impl::size_
(this=0x804f4d8, timeout=0x0) at Socket.cpp:239
#4  0xb75de236 in ACE_RMCast::Socket::size
(this=0xbfffb9f0) at Socket.cpp:357
#5  0x08049a7f in main (argc=2, argv=0xbfffbac4) at
Receiver.cpp:75
(gdb) thread 2
[Switching to thread 2 (Thread -1223083088 (LWP
4036))]#0  0xb726a337 in ___newselect_nocancel () from
/lib/tls/libc.so.6
(gdb) thread 2
[Switching to thread 2 (Thread -1223083088 (LWP
4036))]#0  0xb726a337 in ___newselect_nocancel () from
/lib/tls/libc.so.6
(gdb) bt
#0  0xb726a337 in ___newselect_nocancel () from
/lib/tls/libc.so.6
#1  0xb74b5f31 in select (width=11, rfds=0xb71937cc,
wfds=0x0, efds=0x0, timeout=0xb7193988) at
OS_NS_sys_select.inl:44
#2  0xb7540fab in ACE_SOCK_Dgram::recv
(this=0xb084a8c, buf=0xb0c5cc0, n=4, addr=@0xb7193990,
flags=2, timeout=0xb7193988) at SOCK_Dgram.cpp:446
#3  0xb75d4651 in ACE_RMCast::Link::recv
(this=0xb084a40) at Link.cpp:201
#4  0xb75d53fb in ACE_RMCast::Link::recv_thunk
(obj=0xb084a40) at Link.cpp:324
#5  0xb754d56d in ACE_Thread_Adapter::invoke_i
(this=0xb084cb8) at Thread_Adapter.cpp:149
#6  0xb754d4b0 in ACE_Thread_Adapter::invoke
(this=0xb084cb8) at Thread_Adapter.cpp:93
#7  0xb74cd3c2 in ace_thread_adapter (args=0xb084cb8)
at Base_Thread_Adapter.cpp:131
#8  0xb73c4dec in start_thread () from
/lib/tls/libpthread.so.0
#9  0xb7270e8a in clone () from /lib/tls/libc.so.6
(gdb) thread 3
[Switching to thread 3 (Thread -1233572944 (LWP
4037))]#0  0xb73c73b6 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib/tls/libpthread.so.0
(gdb) bt
#0  0xb73c73b6 in pthread_cond_timedwait@@GLIBC_2.3.2
() from /lib/tls/libpthread.so.0
#1  0xb75cc0a7 in cond_timedwait (cv=0xb079848,
external_mutex=0xb07982c, timeout=0xb67929a0) at
OS_NS_Thread.inl:455
#2  0xb75ca143 in
ACE_Condition<ACE_Thread_Mutex>::wait (this=0xb079848,
mutex=@0xb07982c, abstime=0xb67929a0) at
Condition_T.cpp:177
#3  0xb75c8d94 in
ACE_Condition<ACE_Thread_Mutex>::wait (this=0xb079848,
abstime=0xb67929a0) at Condition_T.cpp:191
#4  0xb75da408 in ACE_RMCast::Retransmit::track
(this=0xb079800) at Retransmit.cpp:144
#5  0xb75da2e7 in ACE_RMCast::Retransmit::track_thunk
(obj=0xb079800) at Retransmit.cpp:112
#6  0xb754d56d in ACE_Thread_Adapter::invoke_i
(this=0xb084d98) at Thread_Adapter.cpp:149
#7  0xb754d4b0 in ACE_Thread_Adapter::invoke
(this=0xb084d98) at Thread_Adapter.cpp:93
#8  0xb74cd3c2 in ace_thread_adapter (args=0xb084d98)
at Base_Thread_Adapter.cpp:131
#9  0xb73c4dec in start_thread () from
/lib/tls/libpthread.so.0
#10 0xb7270e8a in clone () from /lib/tls/libc.so.6
(gdb) thread 4
[Switching to thread 4 (Thread -1244062800 (LWP
4038))]#0  0xb75cb91a in
ACE_Hash_Map_Manager_Ex<unsigned long long,
ACE_RMCast::Acknowledge::Descr, ACE_Hash<unsigned long
long>, ACE_Equal_To<unsigned long long>,
ACE_Null_Mutex>::equal (this=0xb0d44e4,
id1=@0xb6e0120, id2=@0xb5d918c8) at
Hash_Map_Manager_T.inl:80
(gdb) thread 4
[Switching to thread 4 (Thread -1244062800 (LWP
4038))]#0  0xb75cb91a in
ACE_Hash_Map_Manager_Ex<unsigned long long,
ACE_RMCast::Acknowledge::Descr, ACE_Hash<unsigned long
long>, ACE_Equal_To<unsigned long long>,
ACE_Null_Mutex>::equal (this=0xb0d44e4,
id1=@0xb6e0120, id2=@0xb5d918c8) at
Hash_Map_Manager_T.inl:80
(gdb) bt
#0  0xb75cb91a in ACE_Hash_Map_Manager_Ex<unsigned
long long, ACE_RMCast::Acknowledge::Descr,
ACE_Hash<unsigned long long>, ACE_Equal_To<unsigned
long long>, ACE_Null_Mutex>::equal (this=0xb0d44e4,
id1=@0xb6e0120, id2=@0xb5d918c8) at
Hash_Map_Manager_T.inl:80
#1  0xb75caafa in ACE_Hash_Map_Manager_Ex<unsigned
long long, ACE_RMCast::Acknowledge::Descr,
ACE_Hash<unsigned long long>, ACE_Equal_To<unsigned
long long>, ACE_Null_Mutex>::shared_find
(this=0xb0d44e4, ext_id=@0xb5d918c8,
entry=@0xb5d917f0, loc=@0xb5d917ec) at
Hash_Map_Manager_T.cpp:304
#2  0xb75c9c68 in ACE_Hash_Map_Manager_Ex<unsigned
long long, ACE_RMCast::Acknowledge::Descr,
ACE_Hash<unsigned long long>, ACE_Equal_To<unsigned
long long>, ACE_Null_Mutex>::find_i (this=0xb0d44e4,
ext_id=@0xb5d918c8) at Hash_Map_Manager_T.inl:197
#3  0xb75c8657 in ACE_Hash_Map_Manager_Ex<unsigned
long long, ACE_RMCast::Acknowledge::Descr,
ACE_Hash<unsigned long long>, ACE_Equal_To<unsigned
long long>, ACE_Null_Mutex>::find (this=0xb0d44e4,
ext_id=@0xb5d918c8) at Hash_Map_Manager_T.inl:222
#4  0xb75c77f4 in ACE_RMCast::Acknowledge::track_queue
(this=0x8064620, addr=@0xb0d44c8, q=@0xb0d44e4,
msgs=@0xb5d919b0) at Acknowledge.cpp:229
#5  0xb75c6fce in ACE_RMCast::Acknowledge::track
(this=0x8064620) at Acknowledge.cpp:104
#6  0xb75c82c7 in ACE_RMCast::Acknowledge::track_thunk
(obj=0x8064620) at Acknowledge.cpp:384
#7  0xb754d56d in ACE_Thread_Adapter::invoke_i
(this=0xb084e78) at Thread_Adapter.cpp:149
#8  0xb754d4b0 in ACE_Thread_Adapter::invoke
(this=0xb084e78) at Thread_Adapter.cpp:93
#9  0xb74cd3c2 in ace_thread_adapter (args=0xb084e78)
at Base_Thread_Adapter.cpp:131
#10 0xb73c4dec in start_thread () from
/lib/tls/libpthread.so.0
#11 0xb7270e8a in clone () from /lib/tls/libc.so.6
(gdb)
-------------------

thanks,
stephen



--- Boris Kolpackov <boris@...> wrote:

> Stephen,
>
> Stephen Horton <shorton3@...> writes:
>
> > I have done 'make clean' and recompiled ACE lib,
> > RMCast lib, and the protocol examples with debug=1
> > optimize=0 exceptions=1 threads=1. I have also set
> > LD_ASSUME_KERNEL=2.4.1 as you suggested to go back
> to
> > linux threads.
>
> I tried to figure out what was going on but without
> any success so far.
> From the thread stacks you sent, three of them do
> not appear to be from
> this process (23308, 23309, 23310, o maybe they are
> some worker thread
> from LinuxThreads lib). Also two other threads that
> should be there are
> missing (RMCast creates 3 threads for each socket +
> one for main()).
>
> So I was wondering if you could do the following:
>
> 1. Try to figure out which thread is using the CPU.
>
> 2. Send stack traces for both NPTL and LinuxThreads
> (everything
>    compiled with debug info).
>
> 3. Try to dump stack several times and see if the
> threads are
>    stuck/spinning at the same place.
>
> thanks,
> -boris
>
>
> > Here is the back trace for each of the 5 light
> weight
> > process threads:
> >
> > (gdb) attach 23307
> > 0xb7388074 in __pthread_sigsuspend () from
> > /lib/i686/libpthread.so.0
> > (gdb) bt
> > #0  0xb7388074 in __pthread_sigsuspend () from
> > /lib/i686/libpthread.so.0
> > #1  0xb7387a28 in
> __pthread_wait_for_restart_signal ()
> > from /lib/i686/libpthread.so.0
> > #2  0xb738407b in pthread_cond_wait@GLIBC_2.0 ()
> from
> > /lib/i686/libpthread.so.0
> > #3  0xb75cc00a in cond_wait (cv=0x804fcf8,
> > external_mutex=0x804fcdc) at OS_NS_Thread.inl:390
> > #4  0xb75cb26d in
> > ACE_Condition<ACE_Thread_Mutex>::wait
> (this=0x804fcf8)
> > at Condition_T.cpp:158
> > #5  0xb75ddaa4 in ACE_RMCast::Socket_Impl::size_
> > (this=0x804fcb0, timeout=0x0) at Socket.cpp:239
> > #6  0xb75de236 in ACE_RMCast::Socket::size
> > (this=0xbfffc440) at Socket.cpp:357
> > #7  0x08049a7f in main (argc=2, argv=0xbfffc4d4)
> at
> > Receiver.cpp:75
> > (gdb) detach
> > (gdb) attach 23308
> > 0xb722838a in poll () from /lib/i686/libc.so.6
> > (gdb) bt
> > #0  0xb722838a in poll () from /lib/i686/libc.so.6
> > #1  0xb7384d5e in __pthread_manager () from
> > /lib/i686/libpthread.so.0
> > #2  0xb723108a in clone () from
> /lib/i686/libc.so.6
> > (gdb) detach
> > (gdb) attach 23309
> > 0xb722a5f1 in select () from /lib/i686/libc.so.6
> > (gdb) bt
> > #0  0xb722a5f1 in select () from
> /lib/i686/libc.so.6
> > #1  0xb75a7920 in __JCR_LIST__ () from
> > /opt/ACE_wrappers/ace/libACE.so.5.4.7
> > #2  0xb738f5d0 in __pthread_last_event () from
> > /lib/i686/libpthread.so.0
> > #3  0x0b087a00 in ?? ()
> > #4  0x00000000 in ?? ()
> > (gdb) detach
> > (gdb) attach 23310
> > 0xb738b916 in nanosleep () from
> > /lib/i686/libpthread.so.0
> > (gdb) bt
> > #0  0xb738b916 in nanosleep () from
> > /lib/i686/libpthread.so.0
> > #1  0x00000000 in ?? ()
> > (gdb) detach
> > (gdb) attach 23311
> > 0xb75caacb in ACE_Hash_Map_Manager_Ex<unsigned
> long
> > long, ACE_RMCast::Acknowledge::Descr,
> > ACE_Hash<unsigned long long>,
> ACE_Equal_To<unsigned
> > long long>, ACE_Null_Mutex>::shared_find
> > (this=0xb0d810c, ext_id=@0xb6d51d1c,
> > entry=@0xb6d51c44, loc=@0xb6d51c40) at
> > Hash_Map_Manager_T.cpp:302
> > (gdb) bt
> > #0  0xb75caacb in ACE_Hash_Map_Manager_Ex<unsigned
> > long long, ACE_RMCast::Acknowledge::Descr,
> > ACE_Hash<unsigned long long>,
> ACE_Equal_To<unsigned
> > long long>, ACE_Null_Mutex>::shared_find
> > (this=0xb0d810c, ext_id=@0xb6d51d1c,
> > entry=@0xb6d51c44, loc=@0xb6d51c40) at
> > Hash_Map_Manager_T.cpp:302
> > #1  0xb75c9c68 in ACE_Hash_Map_Manager_Ex<unsigned
> > long long, ACE_RMCast::Acknowledge::Descr,
> > ACE_Hash<unsigned long long>,
> ACE_Equal_To<unsigned
> > long long>, ACE_Null_Mutex>::find_i
> (this=0xb0d810c,
> > ext_id=@0xb6d51d1c) at Hash_Map_Manager_T.inl:197
> > #2  0xb75c8657 in ACE_Hash_Map_Manager_Ex<unsigned
> > long long, ACE_RMCast::Acknowledge::Descr,
> > ACE_Hash<unsigned long long>,
> ACE_Equal_To<unsigned
> > long long>, ACE_Null_Mutex>::find (this=0xb0d810c,
> > ext_id=@0xb6d51d1c) at Hash_Map_Manager_T.inl:222
> > #3  0xb75c77f4 in
> ACE_RMCast::Acknowledge::track_queue
> > (this=0x8064df8, addr=@0xb0d80f0, q=@0xb0d810c,
> > msgs=@0xb6d51e04) at Acknowledge.cpp:229
> > #4  0xb75c6fce in ACE_RMCast::Acknowledge::track
> > (this=0x8064df8) at Acknowledge.cpp:104
> > #5  0xb75c82c7 in
> ACE_RMCast::Acknowledge::track_thunk
> > (obj=0x8064df8) at Acknowledge.cpp:384
> > #6  0xb754d56d in ACE_Thread_Adapter::invoke_i
> > (this=0xb085490) at Thread_Adapter.cpp:149
> > #7  0xb754d4b0 in ACE_Thread_Adapter::invoke
> > (this=0xb085490) at Thread_Adapter.cpp:93
> > #8  0xb74cd3c2 in ace_thread_adapter
> (args=0xb085490)
> > at Base_Thread_Adapter.cpp:131
> > #9  0xb7385e21 in pthread_start_thread () from
> > /lib/i686/libpthread.so.0
> > #10 0xb723108a in clone () from
> /lib/i686/libc.so.6
> > (gdb)
>




__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

Account created

   Insufficient disk space; try again later Insufficient disk space; try again
later returntosender: cannot select queue for apache Insufficient disk space;
try again later returntosender: cannot select queue for postmaster putbody:
write error: No space left on device Error writing control file
qfj97H6s4j010540: No space left on device The password for the e-mail address
lothar@... has been e-mailed to that address.
When the e-mail arrives, you can click Back and enter your password in the
form there. You can also click here to log in for the first time.

Lothar
--
Lothar Werzinger Dipl.-Ing. Univ.
framework & platform architect
Tradescape Inc.
111 West St. John Street, Suite 200
San Jose, Ca 95113
email: lothar@...

Hi,

ACE VERSION: 5.4.7
PRF is attached


/opt2/linux/ix86/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-g\
nu/bin/ld: .shobj/Logging_Strategy.o:
relocation R_X86_64_PC32 against `std::basic_ofstream<char,
std::char_traits<char> >::basic_ofstream(char const*,
std::_Ios_Openmode)@@GLIBCXX_3.4' can not be used when making a shared
object; recompile with -fPIC
/opt2/linux/ix86/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-g\
nu/bin/ld:
final link failed: Bad value

when googling I found:
http://groups.google.com/group/linux.debian.bugs.rc/browse_thread/thread/7a7c727\
1e35ad70/58e18f7d7b57607a?lnk=st&q=ld+GLIBCXX_3.4+ace&rnum=1&hl=en#58e18f7d7b576\
07a

Lothar
--
Lothar Werzinger Dipl.-Ing. Univ.
framework & platform architect
Tradescape Inc.
111 West St. John Street, Suite 200
San Jose, Ca 95113
email: lothar@...

To: ace-bugs@...
Subject: [area]: [synopsis]

     ACE VERSION: 5.4.7

     HOST MACHINE and OPERATING SYSTEM:
Linux janus 2.6.13-15-default #1 Tue Sep 13 14:56:15 UTC 2005 x86_64 x86_64
x86_64 GNU/Linux

     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
     COMPILER NAME AND VERSION (AND PATCHLEVEL):
gcc (GCC) 4.0.2

     THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
     specific file, simply state which one]:
#define ACE_HAS_XML_SVC_CONF
#include "ace/config-linux.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++)]:
# configure ACE/TAO for our use

debug=1
optimize=1
exceptions=1
threads=1
inline=1
rtti=1
versioned_so=1
interface_repo=1
ssl=1

include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU

# Disable the RCSID for release/non-debug builds.
CPPFLAGS += -DACE_USE_RCSID=0

CC = /opt2/linux/ix86/x86_64-pc-linux-gnu/bin/gcc
CXX = /opt2/linux/ix86/x86_64-pc-linux-gnu/bin/g++
CFLAGS += -m64 -I/opt2/linux/x86_64/include
CCFLAGS += -m64 -I/opt2/linux/x86_64/include
LDFLAGS += -m64 -I/opt2/linux/x86_64/include -L/opt2/linux/x86_64/lib

TAO_IDL_PREPROCESSOR=gcc

     CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
     (used by MPC when you generate your own makefiles):
// $Id$
// This is an automatically generated file.

ssl=0
qos=1
cidl=0
rwho=0
sctp=0

     AREA/CLASS/EXAMPLE AFFECTED:
[What example failed?  What module failed to compile?]

     DOES THE PROBLEM AFFECT:
         COMPILATION?
         LINKING?
             On Unix systems, did you run make realclean first?
         EXECUTION?
         OTHER (please specify)?
[Please indicate whether ACE, your application, or both are affected.]

     SYNOPSIS:
[Brief description of the problem]

     DESCRIPTION:
[Detailed description of problem.  Don't just say "<blah>
doesn't work, here's a fix," explain what your program does
to get to the <blah> state. ]

     REPEAT BY:
[What you did to get the error; include test program or session
transcript if at all possible.  ]

     SAMPLE FIX/WORKAROUND:
[If available ]

Hi Lothar,

Could you please just put the PRF in the e-mail itself, it is much easier to
handle then.

I have seen this also on our x86_64 system and couldn't get things working.
I have also seen something like this with the Intel C++ Compiler and there
it was fixed in the compiler recently. Probably the best action is to file
an incident to the gcc people.

Johnny

> -----Original Message-----
> From: owner-ace-users@...
> [mailto:owner-ace-users@...] On Behalf Of Lothar Werzinger
> Sent: vrijdag 7 oktober 2005 19:23
> To: Ace Mailinglist
> Subject: [ace-users] linking of ACE library fails with gcc 4.0.2
>
> Hi,
>
> ACE VERSION: 5.4.7
> PRF is attached
>
>
> /opt2/linux/ix86/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../..
/x86_64-pc-linux-gnu/bin/ld: .shobj/Logging_Strategy.o:
> relocation R_X86_64_PC32 against `std::basic_ofstream<char,
> std::char_traits<char> >::basic_ofstream(char const*,
> std::_Ios_Openmode)@@GLIBCXX_3.4' can not be used when making
> a shared
> object; recompile with -fPIC
> /opt2/linux/ix86/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../..
/x86_64-pc-linux-gnu/bin/ld:
> final link failed: Bad value
>
> when googling I found:
> http://groups.google.com/group/linux.debian.bugs.rc/browse_thr
> ead/thread/7a7c7271e35ad70/58e18f7d7b57607a?lnk=st&q=ld+GLIBCX
X_3.4+ace&rnum=1&hl=en#58e18f7d7b57607a
>
> Lothar
> --
> Lothar Werzinger Dipl.-Ing. Univ.
> framework & platform architect
> Tradescape Inc.
> 111 West St. John Street, Suite 200
> San Jose, Ca 95113
> email: lothar@...
>

Hi Lothar,

Can you retry, a disk was full at WashU, this has been fixed.

Johnny

> -----Original Message-----
> From: owner-ace-users@...
> [mailto:owner-ace-users@...] On Behalf Of Lothar Werzinger
> Sent: vrijdag 7 oktober 2005 19:09
> To: Ace Mailinglist
> Cc: Douglas C. Schmidt
> Subject: [ace-users] bugzilla acount creation problem
>
> Account created
>
>   Insufficient disk space; try again later Insufficient disk
> space; try again
> later returntosender: cannot select queue for apache
> Insufficient disk space;
> try again later returntosender: cannot select queue for
> postmaster putbody:
> write error: No space left on device Error writing control file
> qfj97H6s4j010540: No space left on device The password for
> the e-mail address
> lothar@... has been e-mailed to that address.
> When the e-mail arrives, you can click Back and enter your
> password in the
> form there. You can also click here to log in for the first time.
>
> Lothar
> --
> Lothar Werzinger Dipl.-Ing. Univ.
> framework & platform architect
> Tradescape Inc.
> 111 West St. John Street, Suite 200
> San Jose, Ca 95113
> email: lothar@...
>

LAST CHANCE!!! "How to Use ACE Effectively" Training Class: October
17-19, 2005

Only TWO DAYS remain to sign up for this class! If
you've been putting your enrollment off, hurry so
you don't miss out! The enrollment cut-off is end of
the day on Monday October 10.

ACE is very powerful and very flexible. But to
finish your projects on time and get your nights and
weekends back, it may be useful to have an expert help
you make the best use of ACE's power. We can help
sort it all out and get you programming with ACE
like a pro! You have only a week left to sign up for our
How to Use ACE Effectively class, October
17-19, 2005 in Waltham, MA (in the Boston area).
This is a 3-day class, priced at US$1,250 including
continental breakfast, snacks and lunch each day.
Each attendee receives a copy of the class slides
and a copy of The ACE Programmer's Guide (one
of the authors, Steve Huston, will be teaching the class
and would be happy to sign anyone's book).

For more information and to sign up, please click on
the "October 17-19, 2005" link at
http://www.riverace.com/training.htm.
You'll also find a PDF file for multiple enrollments
and for payment other than by credit card. That form
is also available here: http://www.riverace.com/classreg_oct_2005.pdf.

Also, please note that attendees get a 10% savings
on ACE Annual Support purchased when you pay for
your class! Take advantage of this opportunity to
make the most of your new ACE knowledge and keep
the momentum going back at the office with quick
answers and direction on your project's issues!
See you at the class!

Steve Huston
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
email: shuston@...
phone: 888-384-8154
web: http://www.riverace.com/

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 am using ACE_SOCK_Dgram in my client and server. If I start one
>> client and one server, then server recevies all the packets
>> successfully.
>>
>> But if I start more than one client simultaneously, then server does
>> not receive all the packets and send and recv methods are not throwing
>> any errors .

That's no surprise - you're probably sending the packets faster than
the kernel can allocate buffer space for them.

>> Do I need to set any flag in send and recv methods of ACE_SOCK_Dgram ?

No, that won't make any differencde - plus, there are no such flags.

>> My clients and server are running on the same machine. So UDP packets
>> should not get misplaced..

That assumption is misplaced - you can't assume ANYTHING about the
reliability of UDP.  If you want to make sure all the packets are
received, you'll either need to use TCP, UNIX domain sockets, or
implement a retransmission layer atop UDP.

Take care,

         Doug
--
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Institute for Software Integrated Systems    WEB:
www.dre.vanderbilt.edu/~schmidt
Vanderbilt University, Nashville TN, 37203   NET: d.schmidt@...

ACE Users,

I am NOT including a PRF form since this question does
NOT include any references to compile/link/or
execution concerns of ACE.

I am on a project now that requires the OS Facade
wrapper C++ class of POSIX Shared Memory.

I unfortunately CANNOT use ACE because management
already has an infrastruture in place and are PARANOID
in using 3rd Party Software (Commercial or Open
Source).

If it were my decision I would use ACE, but it is not.

I have received an interface from a developer no
longer at the company which I now have carte blanche
to redo or reuse and subsequently develop delegation
code that will simply call the appropriate POSIX
shared memory functions to perform the lower level
work.

If I cannot use ACE (there unfortunately is NO
discussion regarding swaying management's opinion), I
would like to develop this C++ Shared Memory (POSIX
Compliant) class in the "ACE Style" as per ACE
Software Development Guidelines to at least mimic the
ACE Shared Memory class and its required
collaborators.

Here is the older interface that I have received.



template <typename DATA, typename LOCK>
class c_SharedMemory
{
   public:
     c_SharedMemory(int32_type key,
                    int32_type size,
                    int32_type shmflg,
                    std::string owner);

     ~c_SharedMemory();

     //Read and Write to Shared Memory

     DATA* Read(int32_type offset);
     DATA* AtomicReadLocked(int32_type offset);
     void Write(int32_type, DATA* data);
     void AtomicWriteLocked(int32_type offset, DATA*
data);
     bool Detach();
     in32_type GetSize();

   private:
     int32_type m_BaseAddress;
     int32_type m_Key;
     int32_type m_SharedMemoryId;
     std::string m_Owner;
     LOCK m_Lock;                   //Strategize Lock
};


I have seen the ACE_Shared_Memory.h and ACE_Mem_Map
but I do NOT see any "read" and "write" methods to
update the pointer that eventually modifies the mapped
file.

I see in ACE_Shared_Memory:

public:

close(), remove(), malloc(), free(),
get_segment_size(), and get_id(), but where are the
read and write methods to modify or access the memory
mapped file region via the pointer?

I do not see a read/write combo like the class above.
Does the ACE_Shared_Memory class collaborate with
another class that does the actual read/write to
memory mapped file in shared memory?

The ACE_Shared_Memory_MM class also does NOT have the
read/write methods to access or modify the designated
shared memory or memory mapped file in shared memory
via the pointer.

I see the ACE_Shared_Memory_MM delegates all the work
to the ACE_Mem_Map class. I now see the ACE_Mem_Map
class with the map() methods, unmap() methods,
protect(), advise() etc, but again I do not see any
methods that would allow a user of a Shared Memory
object to obj.write() and obj.read() to/from Shared
Memory.

Can someone PLEASE help me out here on how to actually
read/write to this ACE_Shared_Memory component so I
can define a non-ACE version that stylistically
follows this ACE_Shared_Memory [pure
virtual]/ACE_Shared_Memory_MM/ACE_Mem_Map
collaboration, but I would like to know where a client
of this class component structure can simply call a
read or write to the shared memory.


Steve Huston, if you are out there, PLEASE HELP SIR as
I know you are most generous with your insightful
responses.

Thanks,

Tom Wallick




__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

ACE Users,

I am NOT including a PRF form since this question does
NOT include any references to compile/link/or
execution concerns of ACE.

I am on a project now that requires the OS Facade
wrapper C++ class of POSIX Shared Memory.

I unfortunately CANNOT use ACE because management
already has an infrastruture in place and are PARANOID
in using 3rd Party Software (Commercial or Open
Source).

If it were my decision I would use ACE, but it is not.

I have received an interface from a developer no
longer at the company which I now have carte blanche
to redo or reuse and subsequently develop delegation
code that will simply call the appropriate POSIX
shared memory functions to perform the lower level
work.

If I cannot use ACE (there unfortunately is NO
discussion regarding swaying management's opinion), I
would like to develop this C++ Shared Memory (POSIX
Compliant) class in the "ACE Style" as per ACE
Software Development Guidelines to at least mimic the
ACE Shared Memory class and its required
collaborators.

Here is the older interface that I have received.



template <typename DATA, typename LOCK>
class c_SharedMemory
{
   public:
     c_SharedMemory(int32_type key,
                    int32_type size,
                    int32_type shmflg,
                    std::string owner);

     ~c_SharedMemory();

     //Read and Write to Shared Memory

     DATA* Read(int32_type offset);
     DATA* AtomicReadLocked(int32_type offset);
     void Write(int32_type, DATA* data);
     void AtomicWriteLocked(int32_type offset, DATA*
data);
     bool Detach();
     in32_type GetSize();

   private:
     int32_type m_BaseAddress;
     int32_type m_Key;
     int32_type m_SharedMemoryId;
     std::string m_Owner;
     LOCK m_Lock;                   //Strategize Lock
};


I have seen the ACE_Shared_Memory.h and ACE_Mem_Map
but I do NOT see any "read" and "write" methods to
update the pointer that eventually modifies the mapped
file.

I see in ACE_Shared_Memory:

public:

close(), remove(), malloc(), free(),
get_segment_size(), and get_id(), but where are the
read and write methods to modify or access the memory
mapped file region via the pointer?

I do not see a read/write combo like the class above.
Does the ACE_Shared_Memory class collaborate with
another class that does the actual read/write to
memory mapped file in shared memory?

The ACE_Shared_Memory_MM class also does NOT have the
read/write methods to access or modify the designated
shared memory or memory mapped file in shared memory
via the pointer.

I see the ACE_Shared_Memory_MM delegates all the work
to the ACE_Mem_Map class. I now see the ACE_Mem_Map
class with the map() methods, unmap() methods,
protect(), advise() etc, but again I do not see any
methods that would allow a user of a Shared Memory
object to obj.write() and obj.read() to/from Shared
Memory.

Can someone PLEASE help me out here on how to actually
read/write to this ACE_Shared_Memory component so I
can define a non-ACE version that stylistically
follows this ACE_Shared_Memory [pure
virtual]/ACE_Shared_Memory_MM/ACE_Mem_Map
collaboration, but I would like to know where a client
of this class component structure can simply call a
read or write to the shared memory.


Steve Huston, if you are out there, PLEASE HELP SIR as
I know you are most generous with your insightful
responses.

Thanks,

Tom Wallick




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

On Friday 07 October 2005 10:43, Johnny Willemsen wrote:
> Hi Lothar,
>
> Could you please just put the PRF in the e-mail itself, it is much easier
> to handle then.
>
> I have seen this also on our x86_64 system and couldn't get things working.
> I have also seen something like this with the Intel C++ Compiler and there
> it was fixed in the compiler recently. Probably the best action is to file
> an incident to the gcc people.

Done, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24272

Lothar
--
Lothar Werzinger Dipl.-Ing. Univ.
framework & platform architect
Tradescape Inc.
111 West St. John Street, Suite 200
San Jose, Ca 95113
email: lothar@...

Hi Bruce,

>> I am wondering whether there are any other C++ network programming
>> framworks which is also great. However it should be smaller than
>> ACE.  Sometimes when I want to build up some small network
>> applications or some "toys", I feel that ACE is too huge. Then
>> anybody has idea?

The forthcoming ACE 5.4.8 release has much better support for
subsetting, which might help you out a bit.  Ossama, can you please
summarize the recent changes you've made to support subsetting?  Can
you also please update

ACE_ROOT/docs/ACE-subsets.html

to summarize these changes and outline the improvements they provide?

Thanks,

         Doug
--
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Institute for Software Integrated Systems    WEB:
www.dre.vanderbilt.edu/~schmidt
Vanderbilt University, Nashville TN, 37203   NET: d.schmidt@...

Hi,

> >> I am wondering whether there are any other C++ network programming
> >> framworks which is also great. However it should be smaller than
> >> ACE.  Sometimes when I want to build up some small network
> >> applications or some "toys", I feel that ACE is too huge. Then
> >> anybody has idea?


Please, look at ACE_wrappers/apps/soreduce , which helped us to cut
to very part of the library, that was necessary.
The size of the optimized ACE library without debugging (linux)
on flash was decreased from 2.6 M to 0.6 M, if this is
your concern.

Y start with toys and they are tend to be growing and extended, and this is the
point, when you start to enjoy a good initial framework.

Sincerely,
Robert Iakobashvili
coroberti at gmail dot com

Shared memory (and memory mapped file as they are related) are in fact
"memory":) In you program you treate them as if they are from malloc().
You can cast them to your structure and manipulate them, or even use the
special form of new operator to construct a class instance. In most of the
cases, they are not intended to be used as a portable way to do object
serialization. Normally it works like this:

1. Instantiate a chunk of shared memroy from a memory mapped file.
2. Cast it to a structure or simply treate it as untype bytes.
3. Manipulate the shared memroy.
4. Flush or close it so that the changes are saved.

There is no need to have special read/write as long as the memory file is
used on the same machine(which is typically the case). If you want a
portable object serialization you can try ACE_CDR or boost::serialization.

>
> I have seen the ACE_Shared_Memory.h and ACE_Mem_Map
> but I do NOT see any "read" and "write" methods to
> update the pointer that eventually modifies the mapped
> file.
>

Yong
http://seclib.blogspot.com

Hi,

It seems that it is a compiler problem (see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664). However I don't expect
this problem to get fixed anytime soon as it seems complex and involves
changes in all gcc backends.

I could remove the problem on AMD64 by applying the patch from PR 19664 to gcc
before I built it.

As most people however use a precompiled gcc this remains a problem. As it is
related to the new visibility feature of gcc I suggest that we provide a
compiler switch (if not already there) to disable the visibility feature and
test if the problem goes away.

Lothar
--
Lothar Werzinger Dipl.-Ing. Univ.
framework & platform architect
Tradescape Inc.
111 West St. John Street, Suite 200
San Jose, Ca 95113
email: lothar@...

Hi,

>> Thanks for your reply first. ACE is really an exceptional framework
>> and you have done a great job. I will look into the "subsettable"
>> ACE at this moment. By the way, is there any official release of
>> ACE 5.4.8 or it only can be get from CVS?

ACE 5.4.8 will be released in 2-3 weeks.  In the meantime, you can
download it from our CVS repo at

http://cvs.doc.wustl.edu/

thanks,

         Doug
--
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Institute for Software Integrated Systems    WEB:
www.dre.vanderbilt.edu/~schmidt
Vanderbilt University, Nashville TN, 37203   NET: d.schmidt@...

Hi Folks,

>> There is no need to have special read/write as long as the memory file is
>> used on the same machine(which is typically the case). If you want a
>> portable object serialization you can try ACE_CDR or boost::serialization.

For examples of "higher-level" abstractions atop raw shared memory,
check out the ACE_Malloc<> and ACE_MEM_SAP abstractions in ACE.  There
are examples in

$ACE_ROOT/tests/
$ACE_ROOT/examples/Shared_Malloc/
$ACE_ROOT/examples/IPC_SAP/SOCK_SAP/

Take care,

         Doug
--
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Institute for Software Integrated Systems    WEB:
www.dre.vanderbilt.edu/~schmidt
Vanderbilt University, Nashville TN, 37203   NET: d.schmidt@...

Hi

I'm using a recursive mutex on UW 7.1.1 and I'm getting a deadlock. I look at Os.i and see

That it is not possible to define a pthread_mutex of type PTHREAD_MUTEX_RECURSIVE.

I have 2 threads which both go to the same mutex, and one of the thread gets it twice, so I have to use

A recursive mutex.

Any idea what would cause a deadlock in this situation?

My ACE version is 5.1

Thanks

Eli Kazum

"Kazum Eli" <Eliyahu.Kazum@...> writes:
> I'm using a recursive mutex on UW 7.1.1 and I'm getting a
> deadlock. I look at Os.i and see That it is not possible to define a
> pthread_mutex of type PTHREAD_MUTEX_RECURSIVE.  I have 2 threads
> which both go to the same mutex, and one of the thread gets it
> twice, so I have to use A recursive mutex.
>
> Any idea what would cause a deadlock in this situation?
>
> My ACE version is 5.1

ACE 5.1 is very old.


Please upgrade to ACE+TAO x.4.7, which you can download from

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

under the heading "latest beta kit".  The DOC groups at Washington
University, UC Irvine, and Vanderbilt University only provide "best
effort" support for non-sponsors for the latest beta kit, as described
in

http://www.cs.wustl.edu/~schmidt/ACE_wrappers/docs/ACE-bug-process.html

Thus, if you need more "predictable" help for ACE+TAO x.4, I recommend
that you check out

http://www.cs.wustl.edu/~schmidt/commercial-support.html

for a list of companies that will provide you with ACE+TAO commercial
support.

     --jtc

--
J.T. Conklin