Cancelling network operations

Stefan Küng tortoisesvn at gmail.com
Thu Apr 22 11:59:37 EDT 2010


On 22.04.2010 16:23, Bert Huijben wrote:
>
>
>> -----Original Message----- From: neon-bounces at lists.manyfish.co.uk
>> [mailto:neon- bounces at lists.manyfish.co.uk] On Behalf Of Joe Orton
>> Sent: donderdag 22 april 2010 15:38 To: neon at lists.manyfish.co.uk
>> Subject: Re: Cancelling network operations
>>
>> On Thu, Apr 22, 2010 at 03:33:07PM +0200, Bert Huijben wrote:
>>> (This specific case just happened to work better without the
>>> asynchronous connect, because it would just return an error for
>>> the ipv6 variant)
>>
>> Ah, hmmm, I see.  There shouldn't have been any functional change
>> from that patch, are you able to debug that further? (e.g. is the
>> connect() call returning, but the error is not being handled
>> correctly?)
>
> The connect returns WSAEWOULDBLOCK (NE_ISINPROGRESS() returns TRUE),
> but then the connect fails.
>
> This failure would have been reported via the select() that is used
> in raw_poll() if the exceptfds argument was set, but this is NULL.
>
> So it just waits for the timeout.
>
> (Windows doesn't support poll until Windows Server 2008/Windows 7.
> And then it is called WSAPoll())

The only way to cancel a blocked connect() call on Windows pre-Win7 is 
to close the handle from a different thread. Once the handle is closed, 
the connect() call returns immediately with an error.

So maybe exposing the handle so clients could attempt to close it would 
be an option? Or an 'asyncCancel' function in neon which would close the 
handle itself so exposing the internal data (the handle) isn't necessary?


Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net



More information about the neon mailing list