#5088 Modernize Windows channel drivers

obsolete: 8.6b3
open
nobody
8
2012-07-25
2012-07-24
No

As observed after solving 3545365, on Windows the design of the Pipe driver prevents from cleanly cancelling a background flush. Indeed, the write-side worker thread uses synchronous WriteFile()s which cannot be cancelled from another thread across versions of Windows.
The aim of this ticket is to find *any* method to do that as cleanly as possible, with minimal ifdeffery, so that TIP #398 can claim to be working on Windows too, and io-29.33b stop from failing there.

Discussion

1 2 3 > >> (Page 1 of 3)
  • Oh, I remember this problem well :)

    Have a look at CancelSynchronousIo() and CancelIo(). I'm not much use these days at core hackery, so I can't be assigned to this task.

     
    • assigned_to: davygrvy --> nobody
     
  • Here's a worthy project.. Let's move all I/O to overlapped. pipe, file, sockets, console, etc.

    That'll take "a large block of time" but would be worth it to get us up to current/modern practices. My overlapped socket code could share quite a bit with the rest of the core.

     
  • Hi David. Nice that you are still around.

    Even if you do not do much core hackery I hope you will not mind if we might ask you questions. I still remember iocpsock, and maybe we can glean something from there for the pipe driver. Issue might be for which versions of Win* this is supported.

     
  • Heh, x-ed.

    Oh, and nearly last comment in 3545365 was, by ferrieux:

    <quote>
    The FILE_FLAG_OVERLAPPED route seems to be the way to go; however, if we do
    that, we might wonder whether it is still necessary to have worker
    threads... ISTR that some older versions of Windows were unable to include
    a pipe in a WaitForMultipleObjects; I would appreciate an update on this:
    if all currently supported Windows support it, the we could go back to a
    purely event-driven async IO scheme similar to the one in unix.
    </quote>

     
  • Twylite
    Twylite
    2012-07-24

    Hi. Imho the TerminateThread is the way to go. It's actually quite clean, and I'll have a patch available just as soon as patch stops preventing me from applying a diff that I really need in place.

    The FILE_FLAG_OVERLAPPED will have a broad impact on the rest of the implementation, and probably introduce a whole set of new bugs (including subtle synchronisation bugs -- look at what goes on in tclWinSock.c to support blocking operations).

    Tcl dropped support for Windows 2000 some time ago (it no longer compiles against the 2000 Platform SDK), which means the easliest Windows targetted is XP, which does support pipes in WaitForMultipleObjects. That would allow the number of cothreads to be reduced, but at least 1 is still required.

     
  • If I remember correctly, the main notifier uses an alertable mechanism that supports calling a CompletionRoutine from it should that direction be chosen.

     
  • TerminateThread() is not clean! You lose about 2k of stack memory that you can only get back by rebooting

     
  • See MsgWaitForMultipleObjectsEx() with MWMO_ALERTABLE flag.

     
    • assigned_to: nobody --> davygrvy
     
1 2 3 > >> (Page 1 of 3)