guile-devel
[Top][All Lists]
Advanced

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

Re: Unbuffered socket I/O


From: Kevin Ryde
Subject: Re: Unbuffered socket I/O
Date: Wed, 07 Mar 2007 11:20:44 +1100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

address@hidden (Ludovic Courtès) writes:
>
> of `scm_getc ()' translates in one `scm_fill_input ()' call, which in
> turn translates in one `select ()' and one `read ()'

Coming back to this bit: that select really does seem pretty doubtful.
The more I think the more it sounds like a hangover from 1.6 where
select was the only proper place to block if other threads were to
keep running.

But maybe now the right thing would be to have the scm_leave_guile or
scm_without_guile or whatever around each read/write.  Avoiding
initializing an fd_set and whatnot for select would have to be a good
thing.

If so then there'd be other places a similar leave might be wanted,
`copy-file' and `gethost' for instance (I might have mentioned them
before).  Oh well, I guess there's plenty of work for anyone who wants
to investigate ...


One thing I'm pretty sure about though is that the __MINGW32__
conditional on fport_wait_for_input can't be right.  I think we had
bug reports that mingw has pthreads now, so surely anything wanted for
pthreads will be wanted on mingw (or new enough ones or whatever).

Maybe the condition was meant to be "if threads" instead of "if not
mingw".  If configured with null-threads then there'd be no need to
worry about where any blocking happens.




reply via email to

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