Go's place for mkstemp and other POSIX-like functions
Albert Strasheim
There has been some discussion about POSIX-related functionality and
Go:
POSIX standard
http://groups.google.com/group/golang-nuts/browse_thread/thread/170b02d3bc759e5f/6f222a7914ea9e00
POSIX IPC Message Queues
http://groups.google.com/group/golang-nuts/browse_thread/thread/4c105fb71aa6af2f/a4b8be04e9cbb3ba
My question is about the general strategy for adding functions like
mkstemp (defined in 4.3BSD and POSIX.1-2001) to Go.
One option is to call these functions using Cgo. However, in the long
term, having our programs be pure Go would be better since we get to
take advantage of Go debuggers, profilers, etc.
Do we want to rewrite functions like mkstemp in Go? If so, which
package should they be added to?
Can we depend on C implementations on platforms where these functions
are already provided by the C runtime?
In the case of mkstemp, a good reference is perhaps the tempfile
module in Python, which provides some object-oriented APIs on top of
the basic mkstemp functionality.
Any thoughts would be appreciated.
Regards
Albert
peterGo
There has already been some discussion of temporary files.
Temporary files
http://groups.google.com/group/golang-nuts/browse_thread/thread/751318a810ac9538/e51852222e6e2446
Peter
On Jun 2, 5:37 am, Albert Strasheim <full...@gmail.com> wrote:
> Hello all (mostly the Go authors)
>
> There has been some discussion about POSIX-related functionality and
> Go:
>
>
> POSIX IPC Message Queueshttp://groups.google.com/group/golang-nuts/browse_thread/thread/4c105...
Giles Lean
Albert Strasheim <ful...@gmail.com> wrote:
> There has been some discussion about POSIX-related functionality and
> Go:
[ First up: a disclaimer: I'm a contributor to Go, but not one
of the team at Google, who get to make the final choices
about what code does and does not get committed. ]
At least one of those threads was, um, a tad heated. So perhaps
it's best to start over. I suggest (to try to avoid some of the
angst of the previous long thread) that it be stipulated that:
1. POSIX is large, complex, and the result of many years of
history, vendor competition, and compromise;
2. Not all of POSIX is relevant at all to Go (pthreads is
obviously "out" as Go has goroutines);
3. POSIX is the common base for all the non-Windows Go ports
except nacl (currently anyway, I think?)
> My question is about the general strategy for adding functions like
> mkstemp (defined in 4.3BSD and POSIX.1-2001) to Go.
I am on record as saying I want to see access to all system APIs
(at least all _documented_ system APIs -- vendors are getting bad
these days about keeping things secret).
One possibility (which I think I've already suggested, but
which wasn't discussed) would be to have a "posix" module for
things that are poor fits for os, net, and time but which are
available on POSIX-ish systems.
Similarly a "win32" or similar package for Windows where
native Windows functionality is desired there but not on the
other Go ports.
> One option is to call these functions using Cgo. However, in
> the long term, having our programs be pure Go would be
> better since we get to take advantage of Go debuggers,
> profilers, etc.
Yes. I also doubt that cgo can ever be made to work perfectly
in all circumstances, and it adds a speed penalty.
> Do we want to rewrite functions like mkstemp in Go? If so,
> which package should they be added to?
IMHO:
1. yes
2. "posix"
(BTW I have a bunch of POSIX functions done -- my initial
learning exercise -- but not that mkstemp().)
> Can we depend on C implementations on platforms where these
> functions are already provided by the C runtime?
Sometimes we shouldn't (mkstemp() is too simple), somtimes
we'll have to (getpwnam() may use NIS, NIS+, LDAP,
/etc/passwd, /etc/passwd.db, PAM, ...).
DNS name resolution is another case: I'd like to see
nsswitch.conf being used on systems that implement it, as
otherwise Go applications may have different rules for name
resolution to every other application on a system, yet the net
package is avoiding doing so.
(And trust me: there is no "right" context independent answer
to whether one should look at files before DNS, or DNS before
files, nevermind where to position other possibilities like
NIS+.)
> In the case of mkstemp, a good reference is perhaps the
> tempfile module in Python, which provides some
> object-oriented APIs on top of the basic mkstemp
> functionality.
I'd lean toward keeping close to the C version and not
concentrate too much on OO possibilities, myself, although
that's a gut reaction based on my familiarity with the POSIX
API and a desire to keep the learning curve small for what
could be (depending how big a subset were chosen) a rather
large package.
Regards,
Giles
Russ Cox
> package should they be added to?
Yes. Depends on the function.
I just sent out a CL to add TempFile to io/ioutil.
> Can we depend on C implementations on platforms where these functions
> are already provided by the C runtime?
Not in 6g. There is no C runtime.
Russ
Daniel T
> (at least all _documented_ system APIs -- vendors are getting bad
> these days about keeping things secret).
>
> One possibility (which I think I've already suggested, but
> which wasn't discussed) would be to have a "posix" module for
> things that are poor fits for os, net, and time but which are
> available on POSIX-ish systems.
>
> Similarly a "win32" or similar package for Windows where
> native Windows functionality is desired there but not on the
> other Go ports.
>
reaction as well when confronted with an api that appeared foreign to
what was presented (Windows in Go). But I think we can do better then
that. If we disregard current implementations I think there is still
room in design that may call a posix function here and another here
but accomplish function X. I really don't want a large discussion
here, but it is a very interesting topic that might be best suited by
starting a code project external to golang that may start out with
three components: a posix package (or even linux and freebsd), a
windows package, and a designed package, with the first two simply
calls to existing structures, and the last one based on concept. I
think we may find more similarities in work flows and function and
discover areas where there truly are unique calls that we really
should have in a os specific package.
I don't really want to talk bigger then what I have time, but I could
see myself facilitate something like this if there is interest. There
are other areas where a comparative "playground" might be of interest
such as db access; in a way similar to many issues with faced with os
access. Of course, maybe that's what github is for :) .
But I do like the idea of a single package, be it on git or google
code with os specific code for now. I like the idea behind the 99% to
100% of the std go lib is can be called from any os that rationally
supports the concept.
But then, I'm not even a contributer :)
Giles Lean
Daniel T <kard...@gmail.com> wrote:
> But I think we can do better then that. If we disregard
> current implementations I think there is still room in
> design that may call a posix function here and another here
> but accomplish function X.
Nice dream. People have tried -- and tried hard; the best
known success is Cygwin, which manages to get a lot of Unix
functionality onto Windows, but at a fairly horrid performance
cost over native Windows code.
The lowest common denominator is just too low.
The reason I'd like to see something like a posix package is:
o there is sufficient overlap of useful functionality that
doesn't or can't fit comfortably on Windows on the POSIX-ish
platforms to make it useful
o by explicitly not installing a posix package on Windows it
will stop code that uses it from even compiling (versus
putting non-portable code into os, where it will have to
compile but presumably error out at runtime, which is bad)
There will remain OS specific functionality that will never be
portable; a fair amount of that can live in the syscall
package, but especially on the commerical operating systems
too many (for my taste) APIs are defined at the library level,
not the kernel level, and thus can't be accessed from syscall.
So (sounding like a broken record, and probably making many of
the Go team wish for Plan9) I really want access to those APIs
in a smoother manner than cgo provides. But that's for the
future; there is a lot to do before that becomes a pressing
issue.
Giles