GNOME Bugzilla – Bug 691447
[PATCH] modules/system: Add System.exit() API
Last modified: 2013-02-22 04:51:10 UTC
Created attachment 233116 [details] [review] [PATCH] modules/system: Add System.exit() API Kind of lame we didn't have this before. Maybe we should wrap this in GLib? It wouldn't be useful for C users though there. --- modules/system.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-)
Review of attachment 233116 [details] [review]: I don't think this belongs to GLib - all other languages already provide access to exit(). Looks fine to me this way, and it makes a nice parallel with sys.exit() in Python, but I remember Jasper was proposing a Posix module for introspectable glibc functions?
I think it belongs in the POSIX module. The initial support in bug #691030 was turned down, but I think it could work.
(In reply to comment #2) > I think it belongs in the POSIX module. The initial support in bug #691030 was > turned down, but I think it could work. While it's true exit is in POSIX.1-2001, it's also part of C89/C99 as well, and exists on Windows. So while a theoretical gjs app on windows would have to avoid a lot of any POSIX module we might add, it's totally reasonable for it to be able to call exit().
Well, any sort of hand-written system API is what I'm after. I called it the "posix" module because I'm not sure what else to call it.
(In reply to comment #4) > Well, any sort of hand-written system API is what I'm after. I called it the > "posix" module because I'm not sure what else to call it. Again, we can learn from Python here: they have a os module, and a posix module. The posix module holds the C implementations, while os has just python shims that forward to posix (or win32, when on windows). So we would have System.exit() or OS.exit() in JS, forwarding to posix.exit() from introspection. It looks an overkill for exit() alone, but if we are to expose a larger set of the C99 / POSIX.2008 API in a way that's portable across platforms, it looks the best way to me.
(In reply to comment #4) > Well, any sort of hand-written system API is what I'm after. I called it the > "posix" module because I'm not sure what else to call it. Yeah...right now "system" is mostly debugging related stuff. I'll think about this a bit. But OTOH if we can't think of anything else that would live in POSIX, it's probably not worth creating.
(In reply to comment #5) > (In reply to comment #4) > > Well, any sort of hand-written system API is what I'm after. I called it the > > "posix" module because I'm not sure what else to call it. > > Again, we can learn from Python here: they have a os module, and a posix > module. True, but Python is quite different from GLib in that the "os" module looks a lot like POSIX; the win32 semantics are kind of bolted on. > The posix module holds the C implementations, while os has just python > shims that forward to posix (or win32, when on windows). > So we would have System.exit() or OS.exit() in JS, forwarding to posix.exit() > from introspection. > > It looks an overkill for exit() alone, but if we are to expose a larger set of > the C99 / POSIX.2008 API in a way that's portable across platforms, it looks > the best way to me. I could be convinced, but...what other API?
(In reply to comment #7) > (In reply to comment #5) > > (In reply to comment #4) > > > Well, any sort of hand-written system API is what I'm after. I called it the > > > "posix" module because I'm not sure what else to call it. > > > > Again, we can learn from Python here: they have a os module, and a posix > > module. > > True, but Python is quite different from GLib in that the "os" module looks a > lot like POSIX; the win32 semantics are kind of bolted on. > > > The posix module holds the C implementations, while os has just python > > shims that forward to posix (or win32, when on windows). > > So we would have System.exit() or OS.exit() in JS, forwarding to posix.exit() > > from introspection. > > > > It looks an overkill for exit() alone, but if we are to expose a larger set of > > the C99 / POSIX.2008 API in a way that's portable across platforms, it looks > > the best way to me. > > I could be convinced, but...what other API? Good question. Well, looking at Python's os, there is a general usefulness for: - the lower level file descriptor and FS API (open, close, mkdir/mkfifo/mknod, dup, chmod, chown, symlink, link, rename, unlink, rmdir, sync, fdatasync, truncate). Some of fcntl would be useful too, although that's not straightforward to have. Most of these have Gio equivalents, but GSystem proves Gio is not enough - process management API (exit, abort, raise, kill, waitid) Shell has a wrapper for kill. - the credentials API (set/get pid/uid/gid, and all the various combinations thereof)
The system module in gjs is designed for the programming language system, not the computer system. That's why it's mostly about low-level JS details.
So, I think the proper name is "OS": const OS = imports.gi.OS; OS.exit(OS.EXIT_SUCCESS);
(In reply to comment #8) > - the lower level file descriptor and FS API (open, close, mkdir/mkfifo/mknod, > dup, chmod, chown, symlink, link, rename, unlink, rmdir, sync, fdatasync, > truncate). Some of fcntl would be useful too, although that's not > straightforward to have. See: http://git.gnome.org/browse/libgsystem/tree/gsystem-file-utils.h Note that a lot of the above do have Gio equivalents - why would you want open()/close() instead of the GFile ones? Likewise symlink is g_file_make_symbolic_link(). Others exist but are just not necessarily direct. It certainly is annoying to use g_file_set_attributes_from_info() over chmod() for example, and that's why I have a direct wrapper in libgsystem. But on the other hand g_file_set_attributes_from_info() is pretty powerful. fdatasync() is interesting, and I am a heavy user of it. But I've also got custom wrappers for it in libgsystem that are higher level and more like what I want. > Most of these have Gio equivalents, but GSystem proves Gio is not enough Well...I'm kind of using GSystem as a proving ground for stuff that may or may not go into glib. So while it's true that they're not in Gio now, I think for a lot of them it'd be better to land them there than have custom wrapper API in gjs. In particular I think I would cry if we had *another* enumeration wrapping errno... > - process management API (exit, abort, raise, kill, waitid) exit() is the one under discussion. kill() is an interesting case. The others I don't think a gjs app should be calling. > - the credentials API (set/get pid/uid/gid, and all the various combinations > thereof) There is no "setpid" (ok well with patches that I think just landed recently you *can* do it if you're root via clone(), it's for process freezing/thawing but that's not something sane to do in apps). Accessing the current uid/gid makes sense, and those are already covered via GCredentials. I'm not sure it makes sense to expose *set*uid...do we want to encourage people to write gjs apps that run as root?
Hey, what happened of this one? It's acn, and we all agree that exit() is so basic that it's a must have, but was never committed.
(In reply to comment #12) > Hey, what happened of this one? Lots of bikeshedding =) > It's acn, and we all agree that exit() is so basic that it's a must have, but > was never committed. Ok, let's just go with this then.