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

What I want in R^5RS



re: Within the single Lisp with threads domain, I think is no different
    from a thousand other conditions that can arise because of the
    concurrency.  Some thread can mutate some data structure that another
    thread thinks has not been... Some means of locking can be provided,
    but it need not (and probably should not) be specific the file system.

In this particular case  -- I/O "connections" --  there is usually
some underlying, first-class but hidden object that can serve as
the kind of lock that Feeley was hoping for.  So it is different in
the sense that the system implementor _can_ provide a degree of automated
interlocking of attempts to "OPEN" a file for write and/or append access
when some other thread has it "open" also.  

In general, however, Yes it is necessary to provide the end user with
multi-process locking facilities, so that he can protect his own data
structures.  But Marc's request, in this context,  doesn't require one
to punt out to whatever protections the external OS provides (or as in
the case of UNIX,, "doesn't provide"), nor to throw it back into the 
lap of the end-user either.  In fact, the I/O system implementor could 
very well use the same locking capability that is given the end user.


And in truth, No, I don't think these lightweight-threads Schemes add
protection for I/O streams; nor do any Common-Lisp implementations that 
I'm  aware of.



-- JonL --