On Thu, 29 Mar 2012 22:49:26 +0200 Juan Jose Garcia-Ripoll <juanjose.garciarip...@googlemail.com> wrote:
> On Thu, Mar 29, 2012 at 5:57 PM, Juan Jose Garcia-Ripoll < > juanjose.garciarip...@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 ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
