Re: multithreading and begin/end_system_calls

[Vladimir T. <vtz...@gm...>]

On Aug 7, 2008, at 9:13 PM, Sam Steingold wrote:
>
> note that there may be wide ramifications here, e.g., functions  
> which were GC-safe can become GC-unsafe, requiring more changes in  
> their callers.
Yes I encountered exactly such case.

> I think we need begin/end_blocking_system_call in addition to begin/ 
> end_system_call and we need to make the appropriate modification  
> carefully and sparingly.
>
> note also that many system calls which seem unblocking (e.g., stat)  
> may actually be "potentially slow" (think NSF). anyone who has ever  
> done ls on a dead NFS mount just to realize that there is no way to  
> kill the ls process will know what I am talking about.
>
> all "non-instantaneous" system calls will have to be marked  
> "blocking", which does require careful thinking.
Yes, generally any system call that may rely on network performance/ 
availability should be marked as possibly blocking.
Actually any file operation is possibly blocking.

> e.g., what about iconv? does it ever accesses the disk? maybe it  
> keeps some tables for obscure encodings in /usr/share/...?
Hmm - do not know - but if the answer is yes - it can be NFS mounted.

> pathname + streams account for a lion's share of system calls:
These were the first one to cause problems :).

> I think we need to start with marking the blocking calls as such.
> note that a general code review will be necessary to put  
> GC_SAFE_POINT() in many places.
> e.g., length on a circular list may never finish, so we will need  
> to either replace it with a version which checks for circularity,  
> or insert GC_SAFE_POINT() inside the loop - otherwise it may  
> completely block clisp.
When can this happen?

>
> note that GC_SAFE_POINT() is NOT cheap because it invalidates all  
> lisp objects on the C stack, so it will require at least some  
> changes in the code, that can introduce extra pointer dereferencing  
> in tight loops.
>


I agree, the GC_SAFE_POINT() itself is not expensive but all the  
preparation in order to use it may introduce bad performance.
I will define begin/end_blocking_system_call macros as regular system  
calls plus check for GC suspension.
Will try to identify and mark the "non-instantaneous" system calls  
and will post my findings/changes here (as well will commit in the  
threads branch).

BR
   Vladimir