guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making new ports.


From: Gary Houston
Subject: Re: Making new ports.
Date: 9 Oct 2000 22:14:49 -0000

> From: "Dale P. Smith" <address@hidden>
> Date: Fri, 6 Oct 2000 15:26:19 -0400
> 
> Greetings List!
> 
> Well, I got an apache request_rec port working!

Congratulations!

> There is some documentation on make a new port type in the cvs guile
> docs.  Unfortunately, it only does half the job.  The instructions are
> how to create a new port type object (ptob).  There are no
> instructions on how to actually create new ports of that type.

I think there were some things that I didn't feel like documenting
because they were not as clean as they should be, as you noted below.

> By
> browsing the source (is there any other way!), I found four different
> kinds of ports: file, string, soft, and void.  Here is the code that
> creates each of them. (docstrings deleted)

(code deleted)

> I think that the above code needs to generalized to make building user
> defined ports from C easier.
> 
> Something like:
> 
> SCM
> make_new_port(long port_type, void *stream, long mode_bits)
> {
>   SCM port;
>   scm_port *pt;
>   
>   SCM_NEWCELL (port);
>   SCM_DEFER_INTS;
>   pt = scm_add_to_port_table (port);
>   scm_port_non_buffer (pt);
>   SCM_SET_CELL_TYPE (prt, port_type | mode_bits);
>   SCM_SETPTAB_ENTRY (port, pt);
>   SCM_SETSTREAM (port, stream);
>   SCM_ALLOW_INTS;
>   return port;
> }
> The tricky bit is the buffering.  The string ports use the string
> directly as the buffer, the file ports query the os for the best
> buffer size.  Void ports have none.  I guess initially setting the
> port to nonbuffered and changing it later would work.
> 
> Would it be a good idea to factor out the port creation code like this?

It's probably a good start.

> Anyway, Here is what I did to make an apache port from a request_rec
> pointer:

(code deleted)

> It actually works!

In that case it's probably good enough for it's intended purpose!

Note that the new port type doesn't expose its write buffer as the
other port types do.  However I don't think there's any code in Guile
that would be affected: direct access to port buffers is probably only
useful for input.

Since the apache port type is presumably based on a file descriptor,
it's likely that various facilities in Guile would not interact
with it correctly: they are hard-coded for the FPORT type.

E.g., (fileno p) isn't going to work on the Apache port.

Likewise, the scsh-inspired primitives like fdes->ports and
primitive-move->fdes won't work as intended once Apache ports are
created.

This also applies to other types of ports that people may want to
add, so it's a deficiency in the Guile port interfaces and not a
problem which can be easily fixed in the Apache port type.

Gary



reply via email to

[Prev in Thread] Current Thread [Next in Thread]