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/
_______________________________________________
Bug-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-gnustep
