develooper Front page | perl.perl5.porters | Postings from September 2014

[perl #122224] smoke-me/leont/perlio-win32 branch

Thread Next
bulk88 via RT
September 16, 2014 03:49
[perl #122224] smoke-me/leont/perlio-win32 branch
Message ID:
On Mon Sep 15 07:55:12 2014, rjbs wrote:
> Okay, so what's up with this ticket?
> Right now, it looks like Leon has lost tuits or interest, but bulk88
> has not.  Probably the least I can do and still be useful is to get
> bulk88's code up into a smoke-me branch.
> Assuming that smokes clean on Win32, what do we expect to happen with
> this code?  Is this in a state that's hoping for merging?


> Is this
> just a further elaborate experiment?  Obviously there's interest in
> getting this "done," but I want to be clear on what the imagined next
> steps are.

Assuming :win32 layer becomes stable enough (I am making fixes in it), gets better docs (how to create a :win32 IO object with open()), gets a small amount of tests written for it (specifically I need to test does the result of pushing :win32 onto a :unix layer work (and taking ownership of the kernel handle from the C lib)?). After that I'd like to modify it so all handles made from scratch (IE open) are async, then implement :win32 read and write using ReadFileEx/WriteFileEx, then a WaitForSingleObjectEx so $SIG{ALRM} (reimplemented with SetWaitableTimer) will fire and terminate the block.

Instead of ReadFileEx and WaitForSingleObjectEx, I could rewrite :win32 Open to use NtCreateFile and FILE_SYNCHRONOUS_IO_ALERT flag, which means that all read/write/further operations on the handle can instantly fail if a signal cough cough APC ran on the thread. 

But there are 2 problems, Win32 console handles are not kernel IO handles, and are synthesized in user mode using IPC using MS's undocumented clone of Unix domain sockets, so traditional async IO doesn't work on them ever, since it never reaches the kernel (see ), instead you must specifically know its a console handle and special case it using console specific function calls.

2nd problem, perl's pipe() calls to MS C lib, and MS C lib always creates blocking pipes (not async pipes), so doing async IO on them will be blocking.

Possible solution, marshall off all :win32 layer reads and writes to a kernel32 thread pool thread?

> bulk88:  If you point me at a remote, it would help me get this into a
> smoke-me branch today.

patch "add /dev/null support to :win32 io layer" is different in that branch than attached to this ticket since I had to fix a podcheck.t fail in it. All 4 patches on that branch are not WIPs.

bulk88 ~ bulk88 at

via perlbug:  queue: perl5 status: open

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About