This morning I have applied a patch sent in by bacek++ to get socket I/O
in Parrot up and running again. I also did a port of that to Win32,
based off the work by bacek and from the previous Win32 implementation.
I'm glad to have this, but there's probably a couple of things that
should be done. I'm scribbling them here to get feedback and in hope
that @other will pick them up. ;-)
1) Apparently it all works well on Linux-y systems, however there's an
issue with Win32. When I run parrot examples/io/httpd.pir, it will serve
pages, but the browser hangs without showing it after it has served the
page. If I hit Esc in the browser (which I guess ends the connection),
only then does it show the page. I have about zero socket programming
experience, so I'm not sure where to start looking. Patches very
welcome. This is ticket #497.
2) I think we will need some more tests for this. Is this something
worth creating a ticket for?
3) Code review and other improvements would be most welcome, of course.
Thanks all,
Jonathan
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
> Hi,
>
> This morning I have applied a patch sent in by bacek++ to get
> socket I/O in Parrot up and running again. I also did a port of
> that to Win32, based off the work by bacek and from the previous
> Win32 implementation.
>
> I'm glad to have this, but there's probably a couple of things that
> should be done. I'm scribbling them here to get feedback and in
> hope that @other will pick them up. ;-)
>
> 1) Apparently it all works well on Linux-y systems, however there's
> an issue with Win32. When I run parrot examples/io/httpd.pir, it
> will serve pages, but the browser hangs without showing it after it
> has served the page. If I hit Esc in the browser (which I guess
> ends the connection), only then does it show the page. I have about
> zero socket programming experience, so I'm not sure where to start
> looking. Patches very welcome. This is ticket #497.
It might be a userspace buffering issue. Possibly, the server is
keeping alive the connection for another request but failed to flush
its output, and resetting the connection causes it to close the
filehandle (flushing the output).
What happens if you telnet in and HEAD / HTTP/1.0?
Josh
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
I added a "Connection: Close" in HTTP response headers in r37718, hope
that helps.
--
Salu2
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Great, thanks bacek and jonathan!
One fix: we deprecated and removed the socket opcodes intentionally. If
socket PMC methods aren't sufficient, we can have socket dynops. (We're
likely moving all the other io ops to dynops too.)
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
I've updated the httpd.pir example to use pmc methods as much as
possible. There were two ops I couldn't eliminate: "socket" and
"sockaddr". There doesn't seem to be a way to create Socket and
SockAddr objects directly and initialize them correctly... there's no
way to set the address of an existing SockAddr object, and no way to
specify e.g. AF_INET, SOCK_STREAM and all of that for an existing Socket
object.
Mark
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
So, methods or vtable functions for those behaviors need to be added.
In the pdd, the Socket PMC has a 'socket' method (essentially parallel
to the 'open' method on the FileHandle PMC). You should be able to
create a Socket PMC with the standard 'new':
$P0 = new 'Socket'
$P1 = new 'Socket', init_hash
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
And $P0."socket"(2, 1, 6) # still need to define some constants
So I'm working on adding an init_pmc vtable and a socket method, the
former calls the latter. One problem I've run into is that the PIO
routines expect to allocate the PMC, whereas the above API implies the
PMC should allocate the underlying PIO socket as needed. Are we somehow
married to the current design, or is it ok if I switch them around?
(The above API to me looks like Parrot_io_socket() should be called by
the Socket PMC, and should return an integer.)
The attached patch implements this for the Socket PMC (I haven't done
SockAddr yet), and the updated httpd example works correctly under
linux. I haven't tested it on win32 yet, and I don't know how sockets
are supposed to work on PIO_OS_STDIO platforms. But is this a valid
approach?
Mark
P.S. I also noticed in Parrot_io_socket_win32 and Parrot_io_socket_unix
that the setsockopt for SO_REUSEADDR was called with an uninitialized
integer, I fixed that too.