From m.thorade at udk-berlin.de Mon Oct 9 11:41:30 2017 From: m.thorade at udk-berlin.de (Matthis Thorade) Date: Mon, 9 Oct 2017 12:41:30 +0200 Subject: [omniORB] Windows Python3 32bit binaries Message-ID: Hi, I greatly appreciate omniORB and use it via the omniORBpy interface in this project (also there just as a user): https://github.com/OpenModelica/OMPython That project packages omniORBpy binaries for the Windows users, but it has to support 32 and? 64 bit Python. It therefore packages version 4.2.0: https://sourceforge.net/projects/omniorb/files/omniORBpy/omniORBpy-4.2.0/ https://github.com/OpenModelica/OMPython/pull/46#issuecomment-332757340 Would it be possible to also offer 32 AND 64 bit binaries for one single release >= 4.2.2 https://sourceforge.net/projects/omniorb/files/omniORBpy/omniORBpy-4.2.2/ That would enable Python3 for 32bit Windows users. One single release with Py2,Py3 and 32,64bit should be sufficient, future releases could then be 64bit ONLY, as done currently. Thank you very much for considering, Matthis From subscribe at teskor.de Tue Oct 24 09:32:35 2017 From: subscribe at teskor.de (Michael Teske) Date: Tue, 24 Oct 2017 10:32:35 +0200 Subject: [omniORB] potential deadlock? Message-ID: <53f285e1-f8aa-7eb1-b385-6a6f74c5521b@teskor.de> Hi, don't know if this is really a problem, but I recently ran a program of mine with TSAN thread-sanitizer and it found this lock-order-inversion (potential deadlock) in omniorb: SocketCollection::Select holds pd_collection_lock (if count >0 in line 269) and calls notifyReadable (line 315) which may call giopServer::notifyRzReadable which wants pd_lock versus giopServer::instantiate holds pd_lock and calls tcpEndpoint::Bind() which calls SocketCollection::addSocket which wants pd_collection_lock Maybe it's not a real problem because giopServer::instantiate is called only on creation time, but I though I'd let you know. Greetings, Michael From sylvain.joyeux at m4x.org Mon Oct 30 13:28:44 2017 From: sylvain.joyeux at m4x.org (Sylvain Joyeux) Date: Mon, 30 Oct 2017 14:28:44 +0100 Subject: [omniORB] Fwd: problem accessing a TAO-based CORBA server on a multihomed setup using omniORB In-Reply-To: References: Message-ID: I've been trying to access a TAO-based CORBA server which is on a multihomed machine. The name service is omniNames and the client is OmniORB-based. The multihomed machine is a VM running Windows. It has an interface (10.0.2.0/24) that connects to the internet through a NAT and a connection-to-host (2.0.10.0/24). I've added the following clientTransportRule: clientTransportRule = 10.0.2.0/255.255.255.0 none = * tcp Connecting fails with a NoUsableProfile error. The decoded IOR gives 1. IIOP 1.2 10.0.2.15 51961 "....RSTX..Y.M.............." TAG_ORB_TYPE 0x54414f00 TAG_CODE_SETS char native code set: ISO-8859-1 char conversion code set: UTF-8 wchar native code set: UTF-16 wchar conversion code set: 2. IIOP 1.2 2.0.10.2 51961 "....RSTX..Y.M.............." TAG_ORB_TYPE 0x54414f00 TAG_CODE_SETS char native code set: ISO-8859-1 char conversion code set: UTF-8 wchar native code set: UTF-16 wchar conversion code set: I've debugged it in the omniorb source code, and it seems that omniorb restricts itself to the first IIOP profile it finds (which would explain the problem). My questions: - is the omniORB behavior intentional ? Is ill-defined in the standard / an omniORB bug / a TAO bug / none of the above ? - do you know if I have a way to make it work ? Thanks Sylvain