Re: [Sbcl-devel] Windows Thread Support and I/O Patches

[Anton K. <an...@sw...>]

Alastair Bridgewater <ala...@gm...> writes:

> In regards to PROBE-FILE, there is an API to check for DOS device
> names, and an API that returns something usable for UNC fileshares.
> This should be implementable without the open-twice hack.

Opening a file with zero dwDesiredAccess is a normal `windows way' of
examining its properties, not something I had to invent. BTW, stat()
from MSVCRT does the same thing under the hood.

DOS-device-related APIs fail with names like \\.\COM9, and it was
exactly what I needed (notice the device number: COM1-COM8 _are_
reserved DOS device names, everything above are available using the NT
device namespace only; other non-DOS device names, like \\.\CNCB0 or
\\.\PhysicalDrive0, are also useful in some cases).

Implicitly opening something twice is indeed a problem (e.g. you can't
open a named pipe in a way unnoticed by the server side); however, it
has nothing to do with PROBE-FILE in itself; rather, OPEN should be
fixed to avoid probing when not asked to (and, as mentioned above,
successfull stat() has the same harmful consequences as a zero-access
CreateFile).

> In regards to stdcall callbacks: The patch was not integrated because
> the calling convention is properly part of the function type, but
> there's no obvious place to hang it in the syntax.  Thinking about it
> now, however, it should be easy enough to create an stdcall-function
> alien type translator and tie it into the existing callback machinery.

I decided to go with a special-case addition to a normal FUNCTION alien
type parser (and unparser, and some code duplicating their functionality
e.g. to produce a FTYPE declaration) (what I'm talking about is a
highly-experimental `tls-63' branch at
https://github.com/akovalenko/sbcl-win32-threads ).

STDCALL-FUNCTION parser is a cleaner solution, but only if we aren't
going to support _other_ calling conventions, both on x86 and on other
platforms where different conventions exist. I'm unsure whether having
REGPARM-FUNCTION and FASTCALL-FUNCTION etc. is a good thing.

> In regards to SetConsoleCtrlHandler: This would require either the
> ability to invoke a callback on a "non-lisp" thread, or explicit
> runtime support.  Either way, this is quite doable.  With the ersatz
> pthreads stuff in the thread port, it might "just" be a matter of
> forcing a SIGINT to be delivered somewhere.

Preferred to go for full foreign thread callback support instead: it's a
_must_ on Windows; e.g. it's required when running as service, handling
COM events, providing multithreaded COM server...

> In regards to different HANDLE kinds at the fd-stream level: Don't use
> fds.  I've said this before, and I'll probably keep saying it until
> someone actually does the work to make it happen.

Some counter-arguments in favor of FDs: (1) they are guaranteed to be
FIXNUMS, which is a good thing; (2) process creation functions in MSVCRT
use a reserved field of STARTUPINFO in an undocumented way to provide FD
inheritance between MSVCRT applications, but FD inheritance itself is
documented; if we ever desire FD inheritance, leaving this task to CRT
is a good thing; (3) there is no dup2() for handles (and cannot be);
(4) some external library code expects SBCL to use FDs. 

> In regards to SAVE-LISP-AND-SURVIVE: SLAD does a GC that ignores stack
> roots, /et cetera/.  Possibilities include: Not doing the GC before
> saving, implementing something like the Smalltalk-80 "system tracer",
> and recognizing that SLAD is a build-process step, not something for
> casual use, and thus not something that /needs/ to be survivable.

I'm a few steps away from specialized fork() replacement, enough to dump
live SBCL core from another process, like I do on Linux. In my
experimental branch, core is memory-mapped when possible, so there would
be no (new, unsolved) problem if the rest of the dynamic space becomes a
pagefile-backed memory section; in the latter case it would be easy to
start a copy of SBCL that remaps it (copy-on-write) and dumps a new core.

As of "recognizing that SLAD is a build-process step": what I need is a
snapshot/rollback support; I don't like the idea that I should stop
wanting it _instead_ of just implementing it, especially where there is
the obvious way of doing it :)

-- 
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia