Discussion:
[omniORB] Pb with python reserved words in idl files
Jimmy DEVEIL
2008-01-23 21:38:14 UTC
Permalink
Hi all,

I've got a problem with a python reserved word in an idl file with omnyORBpy
2.6.1.
This is the idl file:
interface Printer
{
void print (in string message);
};
I generate stub and skeleton by:
omniidl -bpython Printer.idl

And I make the Server like this:
#!/usr/bin/env python

import CORBA, PortableServer, CosNaming
import _GlobalIDL__POA
import sys

class Printer_impl (_GlobalIDL__POA.Printer):
def __init__ (self, name=None):
self.printerName = name or 'DefaultName'
print "++ printer %s is created" % self.printerName

def _print (self, msg):
print "** printer %s prints [%s]" % (self.printerName, msg)

def main (argv):
printerName = argv[1]
orb = CORBA.ORB_init (argv)
poa = orb.resolve_initial_references ("RootPOA")
printer = Printer_impl (printerName)
oprinter = printer._this ()
nc = orb.resolve_initial_references ("NameService")._narrow (
CosNaming.NamingContextExt)
name = nc.to_name (printerName)
nc.bind (name, oprinter)
poa._get_the_POAManager ().activate ()
orb.run ()

if __name__ == '__main__':
import sys
main (sys.argv)

And the Client like this:
import CORBA
import sys

import CosNaming
import _GlobalIDL

class Client:
# Les decorateur de methodes sont inexistant en python 2.3
# omniORB n'est pas installe pour python 2.4
#@staticmethod
def main (argv):
orb = CORBA.ORB_init(argv)

nc = orb.resolve_initial_references("NameService")._narrow(
CosNaming.NamingContextExt)

for i in range(1,int(argv[2])):
printer = nc.resolve_str (argv[1])._narrow(_GlobalIDL.Printer)
printer._print ("this is a message from python")
main=staticmethod(main)

if __name__ == "__main__":
Client.main (sys.argv)

And I have an error when I start the client and call the method (after the
naming service) :
Traceback (most recent call last):
File "Client.py", line 24, in ?
Client.main (sys.argv)
File "Client.py", line 20, in main
printer._print ("this is a message from python")
File "/home/deveil/tmp/tst/CORBA/Printer_idl.py", line 46, in _print
return _omnipy.invoke(self, "print", _0__GlobalIDL.Printer._d__print,
args)
omniORB.CORBA.BAD_OPERATION: Minor: BAD_OPERATION_UnRecognisedOperationName,
COMPLETED_NO.

After a quick search, I found that the real method call on server side is
not _print but print...
And if I change the definition on the server to print, I have a python
syntax error:
File "Server.py", line 12
def print (self, msg):
^
SyntaxError: invalid syntax

Is this a bug ? (the print call in place of _print)

Thx for all,
_______________________
Jimmy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20080123/2423a760/attachment.htm
Duncan Grisby
2008-02-01 23:12:21 UTC
Permalink
Post by Jimmy DEVEIL
I've got a problem with a python reserved word in an idl file with omnyORBpy
2.6.1.
interface Printer
{
void print (in string message);
};
[...]
Post by Jimmy DEVEIL
Is this a bug ? (the print call in place of _print)
It is indeed a bug. It's amazing that nobody has reported it before.
I've fixed it in CVS. The fix will be in the 3.2 release, in the next
week or two.

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
DA SILVA Antonio
2008-02-07 18:38:31 UTC
Permalink
Hi all,

When I declare a parameter as "in" inside an IDL,
it is then implemented as a reference in C++.
How can I store the parameter/data I receive in this
reference without copying it?

For example :

struct Message
{
attribute string to_do;
};

interface Worker
{
boolean addWork( in Message msg );
};

==> implemented as :

class WorkerImpl : public Worker
{
//..................
// I would like to store the msg in a message queue
// without copying it because it can generate performance
// issues.
CORBA::Boolean addWork( const Message& msg )
{
m_queue.store( msg ); // Store a copy of msg...
}
};

Any ideas?

Antonio.
Teemu Torma
2008-02-07 19:42:06 UTC
Permalink
Post by DA SILVA Antonio
When I declare a parameter as "in" inside an IDL,
it is then implemented as a reference in C++.
How can I store the parameter/data I receive in this
reference without copying it?
If the parameter is an sequence, you could make it inout parameter to
get it passed as non-const reference and steal the contents.

Teemu
DA SILVA Antonio
2008-02-07 20:10:15 UTC
Permalink
I'm not sure what you mean, but be carefull with
"in/out" parameters : the parameter is sent by the caller
throught the network to the servant and then sent back
throught the network to the caller even if it is not
modified. It passes 2 times in the network.
It could be network bandwith consuming
in that case...

If you want to use const parameter as a non-const
just use the "const_cast" operator inside your method.
I don't known if this is clean regarding C++ paradigms.

Antonio.
Post by Teemu Torma
Post by DA SILVA Antonio
When I declare a parameter as "in" inside an IDL,
it is then implemented as a reference in C++.
How can I store the parameter/data I receive in this
reference without copying it?
If the parameter is an sequence, you could make it inout parameter to
get it passed as non-const reference and steal the contents.
Teemu
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
--
_________________________
Antonio DA SILVA
C A R A X IT Department
Software Engineer
11 bis rue d'Aguesseau
75008 Paris, FRANCE
Tel +33 (0)1 70 91 67 94
_________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20080207/c27e0d82/attachment-0001.htm
Teemu Torma
2008-02-07 20:19:12 UTC
Permalink
Post by DA SILVA Antonio
I'm not sure what you mean, but be carefull with
"in/out" parameters : the parameter is sent by the caller
throught the network to the servant and then sent back
throught the network to the caller even if it is not
modified. It passes 2 times in the network.
It could be network bandwith consuming
in that case...
If you steal the contents it will get back as an empty sequence for
example, which is not too bad. If it is local caller, there is no
overhead.

I would assume that this is a case of local caller. Otherwise the
overhead of copying would not be something to be too worried about.

Teemu
Wernke zur Borg
2008-02-07 19:32:30 UTC
Permalink
Subject: [omniORB] How avoid copying "in" parameters?
Hi all,
When I declare a parameter as "in" inside an IDL,
it is then implemented as a reference in C++.
How can I store the parameter/data I receive in this
reference without copying it?
struct Message
{
attribute string to_do;
};
interface Worker
{
boolean addWork( in Message msg );
};
class WorkerImpl : public Worker
{
//..................
// I would like to store the msg in a message queue
// without copying it because it can generate performance
// issues.
CORBA::Boolean addWork( const Message& msg )
{
m_queue.store( msg ); // Store a copy of msg...
}
};
Any ideas?
Antonio.
Hi Antonio,

it is not too long ago when I posted the same question to this group.

I'll quote the answer from Duncan Grisby here:

---------------------------------------------------------------------
On Friday 20 July, "Wernke zur Borg" wrote:

[...]
The C++ equivalent for this interface is
// C++
void DataRelay::putData( const Data& d );
Data* DataRelay::getData();
The problem with this is that each data item must be copied at least
once during putData(). Since performance is an issue in my case I am
looking for a way to minimise copying the data. However with the const
argument& I do not see a way to avoid it.
You can't avoid it if you stick with the standard C++ mapping. This is
one of the many issues that makes the C++ mapping far from ideal.

If you're willing to get your hands dirty and make your code omniORB
specific, you can get in at a level below the C++ mapping and avoid the
unnecessary copying. If you look at the code generated by omniidl, in
the SK.cc file, you'll find definitions of call descriptor classes for
each of the IDL operations. Those are the things responsible for
marshalling and unmarshalling arguments, and calling the servant
methods. What you can do is write your own versions of those classes
that do different memory management -- in your case, passing the in
struct argument by pointer instead of const reference.

Then you can override the _dispatch() method of the _impl_ class, which
is the thing responsible for creating the call descriptor and performing
the call.

Hopefully you'll be able to follow the logic through all the generated
code and see how to change it. I wouldn't recommend this path unless
you've definitely established that the data copying is a significant
performance issue, though.

Cheers,

Duncan.

----- end of quote -----

In the end I refrained from making my hands dirty...

Cheers, Wernke
evgeni.rojkov at durr.com ()
2008-02-07 19:49:01 UTC
Permalink
Post by DA SILVA Antonio
//..................
// I would like to store the msg in a message queue
// without copying it because it can generate performance
// issues.
CORBA::Boolean addWork( const Message& msg )
{
m_queue.store( msg ); // Store a copy of msg...
}
I assume you could not skip copying data the input parameter references if the
m_queue should be processed after addWork() returns. In other case you risk
invalid references. It is not CORBA - related, just C++.
Regards, Evgeni

-----Urspr?ngliche Nachricht-----
Von: omniorb-list-***@omniorb-support.com
[mailto:omniorb-list-***@omniorb-support.com] Im Auftrag von DA SILVA
Antonio
Gesendet: Donnerstag, 7. Februar 2008 13:39
An: omniorb-***@omniorb-support.com
Betreff: [omniORB] How avoid copying "in" parameters?



Hi all,

When I declare a parameter as "in" inside an IDL,
it is then implemented as a reference in C++.
How can I store the parameter/data I receive in this
reference without copying it?

For example :

struct Message
{
attribute string to_do;
};

interface Worker
{
boolean addWork( in Message msg );
};

==> implemented as :

class WorkerImpl : public Worker
{
//..................
// I would like to store the msg in a message queue
// without copying it because it can generate performance
// issues.
CORBA::Boolean addWork( const Message& msg )
{
m_queue.store( msg ); // Store a copy of msg...
}
};

Any ideas?

Antonio.
Duncan Grisby
2008-02-08 23:28:09 UTC
Permalink
Post by DA SILVA Antonio
When I declare a parameter as "in" inside an IDL,
it is then implemented as a reference in C++.
How can I store the parameter/data I receive in this
reference without copying it?
As others have said, in general you can't unless you escape the C++
mapping and use omniORB internal interfaces.

Before beginning to contemplate that, have you profiled your application
and found that the copying is actually an issue?

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
DA SILVA Antonio
2008-02-11 17:18:32 UTC
Permalink
Hi Duncan,

I have not profiled my application, I'm just
starting writing new code for my new application!...
I have just noticed this C++ mapping feature in
omniORB and I have just to compromise with it.
In fact it's not a very big prb, it's just an habit
I have : trying to write the better/performant code
I can, as soon as possible in my projects. This why
I choose omniORB : it is, in my opinion, the most
performant CORBA I ever seen.

For the moment, I will use omniORB whitout any
modifications in its internal things.

Antonio.
Post by Duncan Grisby
Post by DA SILVA Antonio
When I declare a parameter as "in" inside an IDL,
it is then implemented as a reference in C++.
How can I store the parameter/data I receive in this
reference without copying it?
As others have said, in general you can't unless you escape the C++
mapping and use omniORB internal interfaces.
Before beginning to contemplate that, have you profiled your application
and found that the copying is actually an issue?
Cheers,
Duncan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20080211/23c0d678/attachment.htm
Loading...