Ah, that was the function I was looking for. Sure, the file descriptor exists in the C library under Windows. But the C library is basically doing exactly the same thing as IronPython is; it's maintaining the file descriptor number as an abstraction on top of the HANDLE that the operating system knows about. So we're dealing two similar abstractions with entirely unrelated interfaces:
IronPython fd built on top of .NET stream built on top of Windows HANDLE, vs clib fd built directly on top of Windows HANDLE To get from the IronPython fd to a clib fd, you need to translate down the first chain and up the second. On Mon, Dec 15, 2008 at 9:37 AM, Tom Wright <[email protected]>wrote: > Not so: Though admittedly you have to do quite a bit of work to get the > file descriptor into .NET. > http://msdn.microsoft.com/en-us/library/bdts1c9x(VS.71).aspx > > To clarify - the C library was written to work with Python (not IronPython) > and is not my code. > > Thanks, > Tom > > Curt Hagenlocher wrote: > >> >> There's no such thing as a file descriptor number in .NET -- or, for that >> matter, in Windows itself! :) (The latter is something of a semantic point, >> of course, as a HANDLE serves something of the same role in Win32 as a file >> descriptor number does in Unix.) >> >> If you have a FileStream, I think you can turn it into a Windows HANDLE by >> saying >> IntPtr handle = stream.SafeFileHandle.DangerousGetHandle(); >> The C library should have a way to convert a HANDLE into a "file >> descriptor", though I wasn't able to identify the function name with a quick >> google. >> I don't see a way to get handles for stdin, stdout or stderr, though, >> except that these ought to be easy to translate by hand. >> On Mon, Dec 15, 2008 at 8:03 AM, Tom Wright < >> [email protected] <mailto:[email protected]>> >> wrote: >> >> Hi, >> >> At the moment file.fileno() returns an arbitrary identifier of a >> python file rather than a true file descriptor. This is >> semi-blocking the Ironclad port of PIL. >> >> Code in PIL gets an integer using fileno() and passes it directly >> to C code where a call to write() is made. To fix this one would >> have to patch PIL, IronPython's file objects or the write function >> provided to C code - none of these feel like a good course of action. >> >> When ctypes is ported to IronPython this may create similar >> problems. Ideally fileno() would return a real file descriptor. >> Would this be possible? >> >> Thanks, >> >> Tom >> Resolver Systems >> _______________________________________________ >> Users mailing list >> [email protected] <mailto:[email protected]> >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > _______________________________________________ > Users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
