This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: mod_guile design problems



> As I was stating some time back, i'm going to write mod_guile,
> which would allow Apache modules to be written in Scheme.

Cool!

> - 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'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.

So, in the comments describing your request_rec smob, note that if the
smob's CDR is zero, that means this is a dead request_rec.  All code
implementing Scheme operations on request_recs should check the smob's
cdr (after checking its type, of course), and signal an error if it's
zero.  (You could wrap up those two tests in a macro together, maybe.)

Then, I assume mod_guile creates the request_rec smob when it begins
handling the request.  It should hold onto that smob.  When the
request is complete, and it knows the destruction of the request_rec
structure is imminent, it should set that smob's cdr to zero.

I'm making a bunch of guesses, but that's the general idea.  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.

> - 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?


> - Memory pools. I haven't found any use for memory pools in Guile
>   since it's already Garbage Collected. I just need some logic to
>   find an appropriate pool for those functions that require one.
>   (e.g. ap_escape_shell_cmd - i'll copy the result so it can be
>   stored in guile independently of the pool)

Again, we've got a lifetime management issue here.  Sometimes it's
best for Guile to make a copy of an object, so Scheme code can assume
objects live until they are irrelevant --- that's the Scheme Way.
Sometimes it's best to mark objects as dead, and let Scheme code get
errors when it tries to operate on them.

> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]