[Ecls-list] Locking strategy (best so far) (unbuffered streams)

[Matthew Mondor]

On Thu, 29 Mar 2012 22:49:26 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> On Thu, Mar 29, 2012 at 5:57 PM, Juan Jose Garcia-Ripoll <
> juanjose.garciaripoll at googlemail.com> wrote:
> 
> > This seems to be a good compromise, using the underlying operating system
> > for waiting and signaling and using a fast atomic path for detecting the
> > lock-free case. First the simple mutex
> 
> 
> The code for that implementation has been uploaded. It is only used on
> POSIX platforms which provide the previously mentioned implementation if
> signals. On other platforms ECL will still use the spinlock with increasing
> waiting times.

When pulling changes, I noticed a conflict with my local changes in
file.d, the part using unbuffered descriptors, and it reminded me that
my local change was to keep buffering with threads.  If I understand
threaded and non-threaded builds would now use unbuffered descriptors.

If ECL included an alternative to stdio buffered functions which
behaviour could be tuned to not block, do you think that this could
solve this issue, or would there be other potential problems?

Using a read(2)/write(2) syscall per character seems really
suboptimal to me, and because by default compilation is rather verbose,
this also affects compilation performance.  I have written stdio
alternatives in the past to solve similar problems, and could probably
help for this...

Also, I didn't look very far yet, but I don't see code in file.d to put
those descriptors non-blocking even in the
ecl_make_file_stream_from_fd() case, so is buffering more of an issue
than blocking?

Thanks,
-- 
Matt