[omniORB] signals, threads, and C++ exceptions

[Duncan Grisby]

On Tuesday 23 July, Alexy Khrabrov wrote:

> A possible problem is, we don't have access to omniORB's
> internal threads, so I ended up with a signal handler
> like this:

If you are using omniORB 3, look at giopServerThreadWrapper in
include/omniORB3/omniORB.h. That allows you to intercept the threads
omniORB creates, and register a signal mask in them.

That functionality is currently missing from omniORB 4. It's on my
list of things to do to put it back in...

[...]
> Another thing I noticed in comparing omniORB and MICO is the
> speed of allocating a sequence one element at a time,
> with seqP->length(++count) in a loop.  Surprisingly, omniORB
> takes _much_ longer, apparently reallocating much more...

I assume MICO is doing batch reallocations. omniORB doesn't do that.
The reason for not batching allocations is that it's potentially very
wasteful to try to second-guess the application, if you guess wrong.
It's easy for the application to do the batch allocation if that's
what it needs. You just use code like

  while (...) {
    ++count;
    if (count > seqP->length()) seqP->length(count*2);
  }
  seqP->length(count);


Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --