Date: Fri, 30 Jun 2006 00:04:19 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: rsync over ssh hang issue understood
Message-ID: <20060630040419.GA9387@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <44A348D1 DOT 6070908 AT netbauds DOT net> <44A4666A DOT 6020108 AT netbauds DOT net> <20060630013916 DOT GA5859 AT trixie DOT casa DOT cgf DOT cx> <ba40711f0606292036q1a5e5e0dw37349a19247ef97c AT mail DOT gmail DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ba40711f0606292036q1a5e5e0dw37349a19247ef97c@mail.gmail.com>
User-Agent: Mutt/1.5.11
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Thu, Jun 29, 2006 at 11:36:41PM -0400, Lev Bishop wrote:
>On 6/29/06, Christopher Faylor wrote:
>>The idea of using threads for pipe writing has been bounced around for
>>a long time.  It doesn't solve the select problem if there are multiple
>>processes writing to one pipe.  That is not a completely unusual event,
>>unfortunately.
>
>Could you be more specific on how it doesn't solve the select problem
>in when there are multiple processes writing on the pipe?  As far as I
>can tell, if (and its a big if) we can build something with threads
>that works for a single process, it should work just as well for
>multiple processes.  Can you give an example sequence of writes and
>selects that illustrates the problem?  (Not that I think the thread
>approach is without problems, I just can't see this one).

Ok.  I just skimmed the proposal before and now I have read it more
thoroughly.  The multi-process problem that I was thinking about may
not be there but it still doesn't seem very foolproof.

If I understand the plan correctly, in the scenario where select says
it's ok to write but it really isn't, the write would return as if it
succeeded and a writer thread would be created which sits around trying
to empty the pipe.  If this happened with a bunch of processes writing
to a pipe, it seems like there would be potential ordering problems if,
say, a master process was telling subprocesses to write to a pipe in
a round robin fashion.  In that scenario, if you have n processes, you
could conceivably have n people, blocking waiting to write to a pipe
and the writes might be executed in random order.

Also, in the sequence of events:

does select say I can write to the pipe?
   yes:  write to the pipe
   no: do something else

The "do something else" will always be "off-by-one" since we can't
actually detect if it is ok to write to a pipe until we actually do the
write to the pipe.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/