Re: port-for-each vs lazy sweep

Hi, I just fixed another bug (similar to the previous one) in the new port table, in HEAD. Thanks, Ludovic. --- orig/libguile/ChangeLog +++ mod/libguile/ChangeLog @@ -1,3 +1,9 @@ +2007-10-27 Ludovic Courtès <[EMAIL PROTECTED]> + + * fports.c (scm_i_evict_port): Expect a port, rather than a pa

Re: port-for-each vs lazy sweep

Hi, [EMAIL PROTECTED] (Ludovic Courtès) writes: > I noticed the (supposedly related) regression compared to 1.8. Consider > this program: > > (define p (open-output-file "TEST-FILE")) > > (setvbuf p _IOFBF 16384) > > (write "hello" p) > > When running it with "guile-1.8 the-program.scm", `

Re: port-for-each vs lazy sweep

Hi, unfortunately, I'm traveling these two weeks, so I have little opportunity to look at this right now. 2007/9/3, Ludovic Courtès <[EMAIL PROTECTED]>: > Hi Han-Wen, > > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > > > Applied, with corrections. > > I noticed the (supposedly related) regressio

Re: port-for-each vs lazy sweep

Hi, [EMAIL PROTECTED] (Ludovic Courtès) writes: > (I suspect that ports used to be flushed when reclaimed, which is no > longer the case with the weak hash table.) Another unpleasant side effect is this: $ guile-config link -pthread -lguile -lltdl -L/usr/local/lib -lgmp -lcrypt -lm -lltdl

Re: port-for-each vs lazy sweep

Hi Han-Wen, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > Applied, with corrections. I noticed the (supposedly related) regression compared to 1.8. Consider this program: (define p (open-output-file "TEST-FILE")) (setvbuf p _IOFBF 16384) (write "hello" p) When running it with "guile-

Re: port-for-each vs lazy sweep

[EMAIL PROTECTED] (Ludovic Courtès) writes: > > `(%make-void-port "r")' would have the same effect Yes, that'd be fine. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel

Re: port-for-each vs lazy sweep

Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > > /* Return a list of ports using a given file descriptor. */ > SCM_DEFINE (scm_fdes_to_ports, "fdes->ports", 1, 0, 0, > (SCM fd), I didn't think of that one. > void > -scm_remove_from_port_table (SCM port) > -#define FUNC_NAME "scm_

Re: port-for-each vs lazy sweep

Ludovic Courtès escreveu: > At any rate, that's certainly an improvement. I think this should go in > HEAD, but probably not in 1.8. Applied, with corrections. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ Guile-deve

Re: port-for-each vs lazy sweep

Hi, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > Ludovic Courtès escreveu: >>> @@ -472,6 +480,7 @@ scm_i_init_guile (SCM_STACKITEM *base) >>>scm_init_backtrace (); /* Requires fluids */ >>>scm_init_fports (); >>>scm_init_strports (); >>> + scm_init_ports (); >>>scm_init_gdbin

Re: port-for-each vs lazy sweep

Ludovic Courtès escreveu: >> @@ -472,6 +480,7 @@ scm_i_init_guile (SCM_STACKITEM *base) >>scm_init_backtrace ();/* Requires fluids */ >>scm_init_fports (); >>scm_init_strports (); >> + scm_init_ports (); >>scm_init_gdbint (); /* Requires strports */ >>scm_init_has

Re: port-for-each vs lazy sweep

Hi, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > @@ -472,6 +480,7 @@ scm_i_init_guile (SCM_STACKITEM *base) >scm_init_backtrace (); /* Requires fluids */ >scm_init_fports (); >scm_init_strports (); > + scm_init_ports (); >scm_init_gdbint (); /* Requires strports *

Re: port-for-each vs lazy sweep

Kevin Ryde escreveu: > I've struck, in 1.8, port-for-each passing a freed cell to its iterator > func. Eg. "guile -s foo.scm" on Hi, Please see the patch attached. Comments welcome. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen diff --git a/libguile/fports.c b/libgu

Re: port-for-each vs lazy sweep

Kevin Ryde escreveu: > (This got me wondering why there's a port table anyway, instead of > independent objects with say a weak hash table for the "list of all > ports" needed by port-for-each and flush-all. Historical reasons I > suppose.) I'm hacking at a patch to junk the table for a weak hash

Re: port-for-each vs lazy sweep

Hi, Kevin Ryde <[EMAIL PROTECTED]> writes: > Actually I see the flush func of a soft port is entirely unused, it's > never called by a force-output because nothing is ever put in the port > buffer as such. The manual could be clearer about what it's supposed to > be for :-(. Maybe that's a bug,

Re: port-for-each vs lazy sweep

Actually I see the flush func of a soft port is entirely unused, it's never called by a force-output because nothing is ever put in the port buffer as such. The manual could be clearer about what it's supposed to be for :-(. At any rate, I put in the failing test below for port-for-each, and I th

Re: port-for-each vs lazy sweep

[EMAIL PROTECTED] (Ludovic Courtès) writes: > > In the latter case, GC would modify the port table, potentially beneath > the feet of functions that iterate over it, or that cached indices > within the table, things like that. I think you're meant to hold scm_i_port_table_mutex if looking at or mo

Re: port-for-each vs lazy sweep

Hi, Kevin Ryde <[EMAIL PROTECTED]> writes: > I suppose either port-for-each should ignore ports which are unmarked > and unswept; or the gc should sweep the port table entries immediately > instead of lazily. Neither sounds pretty, but the latter might be safer > than letting zombies remain in t

port-for-each vs lazy sweep

I've struck, in 1.8, port-for-each passing a freed cell to its iterator func. Eg. "guile -s foo.scm" on (define lst '()) (gc) (gc) (gc) (make-list 1000) (open-input-file "/etc/passwd") (make-list 1000) (open-input-file "/etc/passwd") (make-list 1000) (open-input-fi