Minor POSIX overhaul

[Will Noble]

Hi all,

I modified the POSIX module so that Scheme code instead of C code
manages PID/errno/signal objects. So, where before posix_kill took
a PID record and a signal record, now it takes ints. I think the
comments hinted towards something along these lines. This removes
a good chunk of awkward (in my view) Scheme-written-in-C code.

I put up a repo at bitbucket.org/wnoble/scheme48. I've only tested
the code lightly, and thought lightly about the general approach,
so I definitely would appreciate any suggestions!

Best,
Will

[Taylor R Campbell]

Date: Tue, 25 Oct 2011 12:58:08 -0700
From: Will Noble <***@cow9.org>

I modified the POSIX module so that Scheme code instead of C code
manages PID/errno/signal objects. So, where before posix_kill took
a PID record and a signal record, now it takes ints. I think the
comments hinted towards something along these lines. This removes
a good chunk of awkward (in my view) Scheme-written-in-C code.

Moving the OS's values for all these things into Scheme makes heap
images OS-dependent. That may be appropriate for your application,
but it's an undesirable property for Scheme48 in general.

[Will Noble]

Post by Taylor R Campbell
Date: Tue, 25 Oct 2011 12:58:08 -0700
I modified the POSIX module so that Scheme code instead of C code
manages PID/errno/signal objects. So, where before posix_kill took
a PID record and a signal record, now it takes ints. I think the
comments hinted towards something along these lines. This removes
a good chunk of awkward (in my view) Scheme-written-in-C code.
Moving the OS's values for all these things into Scheme makes heap
images OS-dependent. That may be appropriate for your application,
but it's an undesirable property for Scheme48 in general.

Hi Taylor,

Thanks for the quick respone! Is the issue you mention a problem
even when, as before, symbolic errnos/signals resume correctly
(by name) while numeric ones and PIDs are marked unresumable?
I'm probably misunderstanding something but aren't users free
to grab these records with OS-dependent values and put them
wherever they want, even when C code manages the whole collection?

Best,
Will

[Taylor R Campbell]

(Full reply quoted below for posterity after a forgotten cc.)

Date: Tue, 25 Oct 2011 20:28:17 -0700
From: Will Noble <***@cow9.org>

I haven't changed the way this is accomplished: when POSIX gets initialized
the C code has knowledge of the value of SIGSTOP from the system headers and
has knowledge of the position of (signal stop) in the vector holding all the
named signals, and it conveys this to the Scheme code. I converted the
_rest_ to Scheme.

OK, that sounds reasonable, as long as you are always careful to make
sure that the OS-dependent numbers are ephemeral and don't make their
way into heap images.

It should really be unnecessary to write most of this code by hand,
but avoiding that nicely is hard and takes a lot more effort than I
have time for these days. With apologies to posterity, I put some
sketches up at <http://mumble.net/~campbell/tmp/stubber-20100507.tgz>,
in a wretched, unpresentable state only because I don't expect to get
back to this in the foreseeable future.


Date: Tue, 25 Oct 2011 20:28:17 -0700

(Did you intend to reply privately, without ccing the list?)
Date: Tue, 25 Oct 2011 17:33:39 -0700
Thanks for the quick respone! Is the issue you mention a problem
even when, as before, symbolic errnos/signals resume correctly
(by name) while numeric ones and PIDs are marked unresumable?
You're doing something wrong if you store a pid in a heap image and
hope it means anything useful when you resume the heap image. But
there's nothing wrong with storing an object representing EXDEV or
SIGSTOP in a heap image and using it meaningfully when the heap image
is resumed, independent of what (POSIX) operating system you resume it
on.
Granted, errno and signal numbers tend to be constant across all
Unices, but there are plenty of similar things that aren't. (E.g.,
getaddrinfo's EAI_* values.)

Hi,

Nope. I forgot to cc and I bounced it to the list after I sent it :)

I did exactly what you say: PIDs refuse to be written to heap images; a
signal obtained by calling (signal stop) or an errno obtained from (errno
xdev) retains its value. On the other hand, the signal (integer->signal
300), like the PID, complains when written out.

I haven't changed the way this is accomplished: when POSIX gets initialized
the C code has knowledge of the value of SIGSTOP from the system headers and
has knowledge of the position of (signal stop) in the vector holding all the
named signals, and it conveys this to the Scheme code. I converted the
_rest_ to Scheme.

Best,
Will

[Will Noble]

Post by Taylor R Campbell
It should really be unnecessary to write most of this code by hand,
but avoiding that nicely is hard and takes a lot more effort than I
have time for these days. With apologies to posterity, I put some
sketches up at <http://mumble.net/~campbell/tmp/stubber-20100507.tgz>,
in a wretched, unpresentable state only because I don't expect to get
back to this in the foreseeable future.

Stubber looks very cool! Like the GObject introspection library but with
Scheme instead of specially-formatted C comments. Much nicer. Too bad you
don't have time. I for one would like to see more come of this.

Best,
Will

[Taylor R Campbell]

Date: Sat, 29 Oct 2011 13:26:07 -0700
From: Will Noble <***@cow9.org>

Stubber looks very cool! Like the GObject introspection library but with
Scheme instead of specially-formatted C comments. Much nicer. Too bad you
don't have time. I for one would like to see more come of this.

Do I hear a volunteer?

Unfortunately, the syntax crap is an unbelievably mega-kludgerific
enormous pile of hair -- I don't think it can be expressed more nicely
without some help in Scheme48's macro engine, although I don't
remember any details. And fitting it into a coherent build system is
quite another problem... But I think the basic idea of the language
is sound. If you do want to pick it up, feel free to ask me questions
about the intent, a great deal of which has not been explicated (and
which is excruciatingly easy to get wrong).

[Michael Sperber]

I've finally had time to review these changes - looking good, pulled &
pushed. Thanks!