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] |
"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