bugGNUstep - Bugs: bug #43635, GSSocketOutputStream doesn't allow...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #43635: GSSocketOutputStream doesn't allow to postpone actual writing

Submitted by:  Sergei Golovin <svg>
Submitted on:  Wed 19 Nov 2014 11:50:11 AM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

Thu 20 Nov 2014 09:51:31 AM UTC, comment #3:

Thanks for that ... I applied the NSStream patch (though not the helper patch as it conflicted with your TLS helper changes).
I checked on OSX to see if it accepts zero length writes, and it did in a small test program. So allowing a zero length write is the correct thing to do from a compatibility point of view.

That being said, I don't think it's a good/elegant thing to do ... it can result in a process stuck in a busy-wait state as the run loop repeatedly signals that writing is possible and the handler repeatedly writes nothing. I actually think having your code set a flag to say writing is possible, and then clear that flag when it finally writes is generally a better way of achieving efficient code.

Richard Frith-Macdonald <CaS>
Project Member
Thu 20 Nov 2014 08:52:27 AM UTC, comment #2:

On the next day i am not sure that i was completely wrong :-).
I have found a way to accomplish the goal described in the first comment without changing of GSSocketOutputStream (see the patch attached to the #43631 http://savannah.gnu.org/bugs/?43641). But i have a perception that it is not elegant. So please reconsider this bug report as a change request.

Sergei Golovin <svg>
Wed 19 Nov 2014 01:01:32 PM UTC, comment #1:

Sorry. It seems i have opened this bug report prematurely. Please close it :-D

Sergei Golovin <svg>
Wed 19 Nov 2014 11:50:11 AM UTC, original submission:

The class doesn't allow to postpone actual writing in the case of two streams (input and output) must be opened and the output stream should do writing only when some conditions are met.

Let's consider the Tests/base/NSURL/Helpers/capture.m. The idea of this helper is to capture the request and to write it to a file. It accepts a connection and opens two socket streams ('ip' and 'op'). As NSStream's delegate it receives events from the runloop in the method -[stream:handleEvent:] where it reads from 'ip' and writes to 'op'. The current implementation of the helper allows the case when the hardcoded response is written to the 'op' while the request's bytes aren't read from the 'ip' or the captured data aren't written to the file 'Capture.dat' (and it was always the case in all my tests). The pseudocode of the method:

switch(event)
{
case NSStreamEventHasBytesAvailable: // ip
<reading code>
break;
case NSStreamEventHasSpaceAvailable: // op
<writing code>
break;
}

As you can see we can receive NSStreamEventHasSpaceAvailable before the last NSStreamEventHasBytesAvailable. If we want to enhance the helper by making it's response depending from the request then we have no means to accomplish that. We have to postpone the 'writing code' by introducing a condition:

switch(event)
{
case NSStreamEventHasBytesAvailable: // ip
<reading code setting 'doRespond' when done>
break;
case NSStreamEventHasSpaceAvailable: // op
if(doRespond) {
<writing code>
}
break;
}

In this case we cease to receive NSStreamEventHasSpaceAvailable after the first such event is ignored by the 'if' statement because that pseudocode leaves the 'op' in the state of unhandled event. The runloop ignores the watcher corresponding to such a stream.

The only method which can be used as a cure for the problem is -[_resetEvents:]. But it is private. So without changing API i see only one way. It is to change the -[write:maxLength:] of GSSocketOutputStream to allow '0' as maxLength. The attached patch does it. It also makes the helper capture.m usable and adds the testcase test02.m using the helper.

Sergei Golovin <svg>

 

Attached Files
file #32474:  capture.patch added by svg (9KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by svg (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 20 Nov 2014 09:51:31 AM UTCCaSStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Wed 19 Nov 2014 11:50:11 AM UTCsvgAttached File-=>Added capture.patch, #32474

    Back to the top


    Powered by Savane 3.1-cleanup1