-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, March 18, 2003, at 05:08 PM, Bruce Mitchener wrote:

I've got a pretty simple server using a factory and some protocol objects. This code handles access to an extension module (the details of which are probably not useful, but it is written in C++, wrapped with SWIG) which implements the majority of our application logic.

Just a brief word of warning... while I've had a few good experiences integrating C/C++ code with Python, SWIG has uniformly been horrible. This particular issue is not with SWIG, but it may create interference later on.

The C++ code tends to dump a ton of output to stdout, and when I twistd like this:

twistd -f myveryown.tap

and have a connected protocol instance, the log out put from the C++ code end up getting written directly to the socket and sent to the client.

The reason that you're having this problem is that on the C++ side of things, FD 0,1,2 are just normal FDs. This is due to the fact that we trap the sys.stdout _object_ in python, but we don't keep the file-descriptors around. The Transport of your Protocol is getting created after those FDs have been closed, and is therefore haplessly allocating the FD of stdout by chance. I don't know how to create a file-descriptor in C which translates to function calls on a Python file-type object. In fact, I don't even know if that's possible. However, this is clearly incorrect behavior for cout<< and printf. Can anyone with more experience in this area propose a solution? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+eAgKvVGR4uSOE2wRAkREAJsG/w54utuFUiGoOF5sFTosC0mUyACfWmqk t7YY/4sBaVjtoZQpoqo1YAA= =ygqD -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, March 18, 2003, at 05:08 PM, Bruce Mitchener wrote:

I've got a pretty simple server using a factory and some protocol objects. This code handles access to an extension module (the details of which are probably not useful, but it is written in C++, wrapped with SWIG) which implements the majority of our application logic.

Just a brief word of warning... while I've had a few good experiences integrating C/C++ code with Python, SWIG has uniformly been horrible. This particular issue is not with SWIG, but it may create interference later on.

The C++ code tends to dump a ton of output to stdout, and when I twistd like this:

twistd -f myveryown.tap

and have a connected protocol instance, the log out put from the C++ code end up getting written directly to the socket and sent to the client.

The reason that you're having this problem is that on the C++ side of things, FD 0,1,2 are just normal FDs. This is due to the fact that we trap the sys.stdout _object_ in python, but we don't keep the file-descriptors around. The Transport of your Protocol is getting created after those FDs have been closed, and is therefore haplessly allocating the FD of stdout by chance. I don't know how to create a file-descriptor in C which translates to function calls on a Python file-type object. In fact, I don't even know if that's possible. However, this is clearly incorrect behavior for cout<< and printf. Can anyone with more experience in this area propose a solution? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+eAgKvVGR4uSOE2wRAkREAJsG/w54utuFUiGoOF5sFTosC0mUyACfWmqk t7YY/4sBaVjtoZQpoqo1YAA= =ygqD -----END PGP SIGNATURE-----