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: status on threads support


"ccf::satchell"@hermes.dra.hmg.gb writes:

> Is it too much to ask 
> somebody to take twenty minutes to write something up, and post it to the 
> list, or put it in guile-doc or on the website  or .....?

For me it takes more than twenty minutes, and if I can spare minutes
for Guile I must prioritize other things.  But I agree that this is a
bad situation.

> On a related topic, I would like to understand when control passes
> from one thread to another. Clearly yield, and join-thread do this;
> and I think display does as well. From this I assume that buffered
> i/o initiates a thread switch? However I have a guile programme  that 
> is trying to read from a socket with recv!, and it looks like this blocks 
> everything, not just the thread doing the read. Is this intended?

1. Thread switches ordinarily occur before evaluating expressions.

2. You're right that all blocking I/O should cause thread switch.
   In Guile, this is achieved by not calling any blocking I/O
   functions, but instead use scm_internal_select to block for I/O.
   scm_internal_select administers the necessary thread switching.

3. Not all blocking I/O primitives in Guile use scm_internal_select
   yet.  One month ago, this was because scm_internal_select was at
   an experimental stage.  I think it is time now to move on and use
   it for all I/O blocking.

4. In particular, recv! does not use scm-internal_select.  We should
   fix this.

> My apologies for hectoring busy people who are volunteers, but I am 
> trying to use this stuff in the dark.

It is important that people tell us when Guile doesn't do what they
like.  That way you can push us to do work, even if we don't really
have time to do it!  ;)

Best regards,
/mdj