Bugs and Issues

[Schiller, Bill [FRCO/RTC]]

Hello,

I have been evaluating different cross-platform environment to use on a work
project and I am looking at CommonC++ as one of the options.  I like the
overall design, but during evaluation I have run into what I believe are
some bugs.  I am evaluating this on Suse Linux 7.2.  Here are the problems I
ran into:

-In ~/CommonC++-1.6.1/posix/port.cpp, line 444, the poll command is called
before LeaveMutex which prevents other threads from adding a new SocketPort
to a SocketService.  I moved the LeaveMutex before the poll call but changed
the poll call to the following:
   poll( mfd.getList(), mfd.getSize(), timer );
and also added to ~/CommonC++-1.6.1/posix/thread.h at line 1692 the
following:
   inline int getSize() { return nufds; }
I did this because once you move the poll call outside of the mutex lock,
the count variable is no longer protected.
-Likewise, in ~/CommonC++-1.6.1/posix/serial.cpp, line 1198, I changed the
poll call as follows to protect the count variable.
   poll( mfd.getList(), mfd.getSize(), timer );
-I think that both the SocketService and SerialService share a deficiency.
That is that when the call to Pending, Output or Expired methods on there
port objects, the object called can not safely delete itself.  That's
because after the call, the port->next is used (or the port->getTimer() is
called).  I think that it would make these Service objects a lot easier to
use if the Pending, Output, or Expired methods could safely delete the
object they are called.  For instance, often it is when you are processing
the data read from a socket that you decide the socket object should be
deleted.
-A general concern I have about using this framework is that it looks like
some constructor objects can throw exceptions.  The example I am thinking of
is ~/CommonC++-1.6.1/posix/socket.cpp, line 80 where the Error method is
called.  It looks like this would ultimately throw an exception.  I have
stayed away from throwing exceptions in constructors as it is my
understanding that they are a source of a memory leak (memory is allocated,
exception returns and you have no reference to delete).  Is this approach
something that is generally discouraged in your framework?  If not, how do
you deal with the memory leak issue?

Aside from that, there are a couple objects I have seen in other frameworks
that I would have to create for myself in yours but it wouldn't be that much
trouble to add directly to the framework if you wanted to.
1.  A mutex locker object.  This has a constructor that locks the mutex and
a destructor that releases the mutex.  They are used in a block of code to
synchronize it by declaring a local mutex locker object at the beginning of
the block.  When the block is entered, the mutex is locked (during
allocation for the mutex locker from the stack) and the mutex is released
when the block is exited no matter how/why you exit the block.   This is
nice to allow an exception to be thrown within a synchronized block of code
or if you want to return from the synchronized method early.
2. A simple timer thread that allows multiple threads to queue timer tasks.
The timer thread orders the list of tasks and calls them when they expire.

That's all.  Thanks,

Bill

--------------------------------------
Bill Schiller
Software Engineer
Rosemount Inc.
8200 Market Boulevard
Chanhassen, MN 55317