bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #43635] GSSocketOutputStream doesn't allow to postpone actual writi


From: Sergei Golovin
Subject: [bug #43635] GSSocketOutputStream doesn't allow to postpone actual writing
Date: Wed, 19 Nov 2014 11:50:12 +0000
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0

URL:
  <http://savannah.gnu.org/bugs/?43635>

                 Summary: GSSocketOutputStream doesn't allow to postpone
actual writing
                 Project: GNUstep
            Submitted by: svg
            Submitted on: Wed 19 Nov 2014 03:50:11 PM SAMT
                Category: Base/Foundation
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

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.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Wed 19 Nov 2014 03:50:11 PM SAMT  Name: capture.patch  Size: 9kB   By:
svg

<http://savannah.gnu.org/bugs/download.php?file_id=32474>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?43635>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]