[omniORB] omniORB4: deadlock in giopServer / SocketCollection

[Bastiaan Bakker]

> -----Original Message-----
> From: Duncan Grisby [mailto:dgrisby@uk.research.att.com]
> Sent: Wednesday, February 13, 2002 5:57 PM
> To: Bastiaan Bakker
> Cc: omniORB-list (E-mail) (E-mail)
> Subject: Re: [omniORB] omniORB4: deadlock in giopServer /
> SocketCollection=20
>=20
>=20
> On Tuesday 5 February, "Bastiaan Bakker" wrote:
>=20
> [...several different bugs...]
>=20
> I've checked in changes that hopefully fix all the problems you've
> experienced. Thanks for spending the effort to track them down and fix

Well, thank you for maintaining omniORB! Sending in a few bug reports is =
the least one can do in return.
=20
> them. Despite extensive testing on both Solaris and Linux, I haven't
> once seen select() return EBADF, so there's obviously something
> different about my machines to yours.
>=20

The machine I use is a single CPU netra X1 with 1GB memory:
SunOS t2 5.8 Generic_108528-06 sun4u sparc SUNW,UltraAX-i2
gcc version 2.95.3 20010315 (release)

On this machine I get EBADFs once in a few thousand calls, which is =
quite often, considering the race condition involved. OTOH, on another =
machine, running Linux 2.2.15, I didn't get any during 200.000 calls.=20
This is what makes debugging multihreaded code such a joy :-)
BTW, is your set of tests available somwhere? I like to run it on the =
'problematic' X1 to see if more race conditions will pop up.

 =20

> In the process of investigating these things, I also discovered and
> fixed a couple of silly things that caused far more thread creation
> and thread switching than necessary, so everything should be more
> efficient now too.
>=20

OK, great!

Cheers,

Bastiaan Bakker
LifeLine Networks bv


> Cheers,
>=20
> Duncan.
>=20
> --=20
>  -- Duncan Grisby  \  Research Engineer  --
>   -- AT&T Laboratories Cambridge          --
>    -- http://www.uk.research.att.com/~dpg1 --
>=20