[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sbcl-devel
Subject:    [Sbcl-devel] open_binary() implementation
From:       Matthew Stickney <mtstickney () gmail ! com>
Date:       2017-06-28 20:30:43
Message-ID: CAKH_Ld4CNSCYh7EgH5yBDLq19c69b7=7zjcq5rdxCbD2J86BeQ () mail ! gmail ! com
[Download RAW message or body]

I wanted to allow SBCL executables and core files to support
linux-style unlink-while-open behavior on Windows (as it is, you can't
rename or delete a dumped exe or core file while an SBCL program is
running).

The main issue is that open_binary() in src/runtime/coreparse.c uses
open() on Windows, and the Windows implementation of open() doesn't
set the FILE_SHARE_DELETE attribute when calling CreateFile()
internally. Creating a POSIX-compliant wrapper around CreateFile()
seems intractable.

Given that open_binary() appears to only be used to open core files
(or the current image), and is only used with O_RDONLY, would it be
reasonable to change the name (e.g. to open_core()) and have the
windows implementation use CreateFile() directly? If so, would the
lack of an errno value be a problem (as far as I can tell, only the
return value is checked)?

I'm a little nervous making changes to the core runtime, although this
isn't especially invasive. If somebody has a better idea[1], I'd be
happy to hear it.

-Matt Stickney

[1] Windows has the sopen() function, which acts like open() and takes
an additional sharing mode parameter, but it only allows DOS-style
control bits, which don't include FILE_SHARE_DELETE.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel
[prev in list] [next in list] [prev in thread] [next in thread]