Re: mod_guile design problems

[forcer <forcer@mindless.com>]

Jim Blandy <jimb@red-bean.com> writes:

> > - I want to make smob's for the request_rec, server_rec and
> >   conn_rec structures. Those are actually automagically destroyed
> >   by apache when it's done with it. I have no idea how to handle
> >   this - mod_guile modules can of course store the smob's
> >   wherever they like, and access them even after the real ones
> >   have vanished. sadly, apache does *not* provide a clean way to
> >   register "cleanup"-functions for these structures.
> 
> It's becoming clear that this topic --- how to manage objects in Guile
> whose lifetimes cannot be placed completely under the GC's control ---
> is perhaps the most important issue to address in the section on
> smobs.
> 
> If you were writing in C, how would you, as a programmer, know when
> the *_rec structures get destroyed?  Whatever those rules are, you
> need to make Guile enforce them.

I would only use it in the function in which i was given this
specific request_rec. This is reflected in the approach i chose
(as described in a different post) - the request_rec smob will be
muteable as long as we're in the handling function. When we leave
it, the request_rec smob will be marked "unmuteable" to allow
Scheme modules still to retrieve any information they want, but
to signal an error when they're trying to change any of it (since
this won't have any effect).

> I'll make a guess that the request_rec structure dies when the HTTP
> request has been answered.  I'll make a further guess that, since your
> mod_guile code is answering the request, it knows when this happens.

Actually, a HTTP request is divided into a few sections, on each
of which one can register a callback. Each callback will be
called with a request_rec. It should be the same (modulo any
modifications done by other modules) for each request, but noone
guarantees that. The point where we can assume that a request is
over is when the last phase is called (logging), but a Scheme
module might still want to keep the request_rec around. So i
guess the approach described above is the most senseful.

> You have
> to reflect the true lifetime of the object back at the Scheme level.
> In order to make this work, any interface you're trying to export to
> Guile must give you at least one of the following promises:
> - Guile is in total control over the underlying object's lifetime.  Easy.
> - The interface promises exactly when the object will die.  This is
>   the case I describe above, where I'm assuming your code tells Apache
>   when the request is satisfied, and thus knows when the underlying
>   request_rec structure will die.
> - The interface will actively tell you when the object is destroyed.
>   Easy enough.
> - The interface is passive, but provides some way for your code to
>   reliably test whether a given object has died.  Your interface code
>   has to perform this test on every operation.
- The interface doesn't say anything about any lifetime, but just
  hands in some struct, asks to modify it, and does whatever it
  wants with the struct afterwards.

:]

> > - Apache uses it's own type of FILE pointers, BUFF's.
> >   There seems no way to wrap a BUFF into a guile port and lateron
> >   retrieve the BUFF from the port.
> 
> It seems to me that Guile's ports should be perfect for this.  As
> Chris Bitmead put it, they can be a data source or sink for anything.
> Gary's recent changes should make this work even better.  You just
> need to write your own set of ptob_funs.  What's the specific problem
> here?

I guess the specific problem here is "Lack Of Documentation" - In
the documentation available to me i couldn't find anything about
creating ports (that is, i found the C version of
make-soft-port, but that one does not allow to retrieve any other
information from the port lateron)

> > More or less unrelated to this, i'm also searching for the new
> > Environment specification (i've lost my local copy). I wonder
> > wether it'll be possible to mark an environment as "read-only",
> > e.g. that a set! will not affect that environment or any of it's
> > parents.
> 
> The environment spec gives environments the right to forbid mutations,
> but it doesn't provide any way for an environment to promise to be
> constant.  We do need that in the module system, so a (byte) compiler
> can open-code cons, car, cdr and such.  So I think that question is
> beyond the scope (umm) of the environment spec.

:)
The background to my question was my second goal: A HTML embedded
Scheme. Since those should run in the already linked Guile
interpreter, we need a way to prevent them of overwriting
"official" functions.
Of course the same can be achieved by just copying the
environment and giving those scripts a new top level
environment.
That's why i wanted to know where i can find the current notes
about environments :)
	-forcer

-- 
((email . "forcer@mindless.com")       (www . "http://forcix.cx/")
 (irc   . "forcer@#StarWars (IRCnet)") (gpg . "/other/forcer.gpg"))