[IronPython] IronPython and file descriptors
Curt Hagenlocher
curt at hagenlocher.org
Mon Dec 15 19:27:35 CET 2008
I think I understand the motivation pretty well; what I'm saying is that I
don't see that this is possible. IronPython has no access to the table
being used by the C library to map between Windows HANDLEs and clib file
descriptors, so we can't return a clib-compatible fd.
Even if we were to return a Windows HANDLE as the fd from IronPython
(something which is bad in several ways), this wouldn't be a value that
could just be used directly by the C extension through the C library.
On Mon, Dec 15, 2008 at 10:18 AM, Tom Wright <tom.wright at resolversystems.com
> wrote:
> Agreed. It is certainly possible with some work to get a file descriptor
> and pass it to C code.
>
> This is not the problem, however. Ironclad's aim (eventually) is to allow
> *arbitrary* C extensions to work with Ironpython without changing the
> extensions. Ctypes aim is to allow arbitrary C code to be run by python
> (possibly in other python libraries which you really don't want to modify).
>
> In CPython .fileno() is a file descriptor and some modules use this fact
> (specifically PIL) by passing file descriptors as integers into C code. I do
> not know how one can make this code work in IronPython unless .fileno()
> returns a file descriptor.
>
> The game here is not making a particular C library work with IronPython by
> modifying this library but making as many libraries as possible work without
> modification. Of course whether this is worthwhile depends on how many
> libraries rely on this fact.
>
> Sorry - I hope this is a little clearer.
>
> Tom
>
>
> Curt Hagenlocher wrote:
>
>> 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 <
>> tom.wright at resolversystems.com <mailto:tom.wright at resolversystems.com>>
>> 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
>> <http://msdn.microsoft.com/en-us/library/bdts1c9x%28VS.71%29.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
>> <tom.wright at resolversystems.com
>> <mailto:tom.wright at resolversystems.com>
>> <mailto:tom.wright at resolversystems.com
>> <mailto:tom.wright at resolversystems.com>>> 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
>> Users at lists.ironpython.com
>> <mailto:Users at lists.ironpython.com>
>> <mailto:Users at lists.ironpython.com
>> <mailto:Users at lists.ironpython.com>>
>>
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081215/059b3517/attachment.html>
More information about the Ironpython-users
mailing list