Hi all,
I''ve been working on the win32-pipe library (again) and I''ve
reworked
the interface. Instead of Pipe.new_server or Pipe.new_client, there''s
now a base Pipe class, with Pipe::Server and Pipe::Client subclasses.
You can find the latest code in the CVS repo.
Oh, and you''ll need to update your windows-pr library with the latest
from CVS if you want to use this. I had to add some missing pipe related
error constants to the Windows::Pipe module. These will be included in
windows-pr 0.8.5.
Anyway, I''ve got the synchronous mode working alright. Unfortunately, I
can''t get the asynchronous server to work. When I try to run the
test_server_async.rb code (in CVS) I get this:
VERSION: 0.2.0
win32-pipe/lib/win32/pipe/server.rb:69:in `connect'': Waiting for a
process to open the other end of the pipe. (Win32::Pipe::Error)
from test_server_async.rb:70:in `mainloop''
from test_server_async.rb:101
Any ideas?
Here''s the code, btw:
# test_server_async.rb
require ''win32/pipe''
include Win32
puts "VERSION: " + Pipe::VERSION
Thread.new { loop { sleep 0.01 } } # Allow Ctrl-C
CONNECTING_STATE = 0
READING_STATE = 1
WRITING_STATE = 2
class MyPipe < Pipe::Server
def connected
puts "connected"
@state = READING_STATE
end
def read_complete
puts "read_complete"
puts "Got [#{buffer}]"
@state = WRITING_STATE
end
def write_complete
puts "write_complete"
close
@state = CONNECTING_STATE
end
def reconnect
close
mainloop
end
def mainloop
@state = CONNECTING_STATE
while true
if wait(1) # wait for 1 second
if pending? # IO is pending
case @state
when CONNECTING_STATE
connected
when READING_STATE
if transferred == 0
reconnect
break
end
read_complete
when WRITING_STATE
if transferred != length
reconnect
break
end
write_complete
end
end
case @state
when CONNECTING_STATE
if connect
connected
end
when READING_STATE
if read
if not pending?
read_complete
end
else
reconnect
end
when WRITING_STATE
if write("Thanks for the data!")
if not pending?
write_complete
end
else
reconnect
break
end
end
end
sleep(1)
puts "pipe server is running"
end
end
end
pserver = MyPipe.new(''foo'', true)
pserver.mainloop
pserver.close
Hi, 2008/5/20 Daniel Berger <djberg96 at gmail.com>:> Hi all, > > I''ve been working on the win32-pipe library (again) and I''ve reworked the > interface. Instead of Pipe.new_server or Pipe.new_client, there''s now a base > Pipe class, with Pipe::Server and Pipe::Client subclasses. You can find the > latest code in the CVS repo. > > Oh, and you''ll need to update your windows-pr library with the latest from > CVS if you want to use this. I had to add some missing pipe related error > constants to the Windows::Pipe module. These will be included in windows-pr > 0.8.5. > > Anyway, I''ve got the synchronous mode working alright. Unfortunately, I > can''t get the asynchronous server to work. When I try to run the > test_server_async.rb code (in CVS) I get this: > > VERSION: 0.2.0 > win32-pipe/lib/win32/pipe/server.rb:69:in `connect'': Waiting for a > process to open the other end of the pipe. (Win32::Pipe::Error) > from test_server_async.rb:70:in `mainloop'' > from test_server_async.rb:101 > > Any ideas? >Because ERROR_PIPE_LISTENING (536) is not an actual error, just ignore it like this: case error when ERROR_IO_PENDING @pending_io = true when ERROR_PIPE_CONNECTED unless SetEvent(@handle) raise Error, get_last_error(error) end when ERROR_PIPE_LISTENING # do nothing else raise Error, get_last_error(error) end Regards, Park Heesob
Heesob Park wrote:> Hi, > > 2008/5/20 Daniel Berger <djberg96 at gmail.com>: >> Hi all, >> >> I''ve been working on the win32-pipe library (again) and I''ve reworked the >> interface. Instead of Pipe.new_server or Pipe.new_client, there''s now a base >> Pipe class, with Pipe::Server and Pipe::Client subclasses. You can find the >> latest code in the CVS repo. >> >> Oh, and you''ll need to update your windows-pr library with the latest from >> CVS if you want to use this. I had to add some missing pipe related error >> constants to the Windows::Pipe module. These will be included in windows-pr >> 0.8.5. >> >> Anyway, I''ve got the synchronous mode working alright. Unfortunately, I >> can''t get the asynchronous server to work. When I try to run the >> test_server_async.rb code (in CVS) I get this: >> >> VERSION: 0.2.0 >> win32-pipe/lib/win32/pipe/server.rb:69:in `connect'': Waiting for a >> process to open the other end of the pipe. (Win32::Pipe::Error) >> from test_server_async.rb:70:in `mainloop'' >> from test_server_async.rb:101 >> >> Any ideas? >> > Because ERROR_PIPE_LISTENING (536) is not an actual error, just ignore > it like this: > > case error > when ERROR_IO_PENDING > @pending_io = true > when ERROR_PIPE_CONNECTED > unless SetEvent(@handle) > raise Error, get_last_error(error) > end > when ERROR_PIPE_LISTENING > # do nothing > else > raise Error, get_last_error(error) > endAh, that definitely improved things, thanks. I also fixed up the test_client_async.rb script, btw. However, I''ve botched something else up. I started up the test_async_server.rb program in one terminal, then ran the test_client_async.rb program. The first time it works on the client side: # Client side Connected... write_complete pipe client is running read_complete Got [Ruby rocks!] back from server Though I see nothing on the server side. The second time I run the client it just hangs. I fixed something in the Pipe#wait method (so update from CVS) but that didn''t solve it. Any ideas? Thanks, Dan
2008/5/20 Daniel Berger <djberg96 at gmail.com>:> Heesob Park wrote: >> >> Hi, >> >> 2008/5/20 Daniel Berger <djberg96 at gmail.com>: >>> >>> Hi all, >>><snip>> > However, I''ve botched something else up. I started up the > test_async_server.rb program in one terminal, then ran the > test_client_async.rb program. The first time it works on the client side: > > # Client side > Connected... > write_complete > pipe client is running > read_complete > Got [Ruby rocks!] back from server > > Though I see nothing on the server side. > > The second time I run the client it just hangs. > > I fixed something in the Pipe#wait method (so update from CVS) but that > didn''t solve it. > > Any ideas? >Here is the patch for pipe.rb and server.rb: --- win32-pipe/lib/win32/pipe.rb 2008-05-20 14:10:30.000000000 +0900 +++ pipe.rb 2008-05-20 17:07:53.000000000 +0900 @@ -62,7 +61,7 @@ # def close DisconnectNamedPipe(@pipe) - CloseHandle(@pipe) + # CloseHandle(@pipe) end # Returns whether or not there is a pending IO operation on the pipe. @@ -76,6 +75,7 @@ # def read bytes = [0].pack(''L'') + @buffer = 0.chr * PIPE_BUFFER_SIZE if @asynchronous bool = ReadFile(@pipe, @buffer, @buffer.size, bytes, @overlapped) @@ -83,13 +83,13 @@ if bool && bytes_read > 0 @pending_io = false - @buffer[bytes_read] = 0 + @buffer = @buffer[0,bytes_read] return true end error = GetLastError() if !bool && error == ERROR_IO_PENDING - @pending = true + @pending_io = true return true end --- win32-pipe/lib/win32/pipe/server.rb 2008-05-20 14:10:30.000000000 +0900 +++ server.rb 2008-05-20 16:54:23.000000000 +0900 @@ -9,13 +9,10 @@ super(name, asynchronous) @open_mode = PIPE_ACCESS_DUPLEX - @pipe_mode = PIPE_TYPE_BYTE | PIPE_READMODE_BYTE + @pipe_mode = PIPE_TYPE_BYTE | PIPE_READMODE_BYTE | PIPE_WAIT if @asynchronous - @pipe_mode |= PIPE_NOWAIT @open_mode |= FILE_FLAG_OVERLAPPED - else - @pipe_mode |= PIPE_WAIT end Regards, Park Heesob
Heesob Park wrote:> 2008/5/20 Daniel Berger <djberg96 at gmail.com>: >> Heesob Park wrote: >>> Hi, >>> >>> 2008/5/20 Daniel Berger <djberg96 at gmail.com>: >>>> Hi all, >>>> > <snip> >> However, I''ve botched something else up. I started up the >> test_async_server.rb program in one terminal, then ran the >> test_client_async.rb program. The first time it works on the client side: >> >> # Client side >> Connected... >> write_complete >> pipe client is running >> read_complete >> Got [Ruby rocks!] back from server >> >> Though I see nothing on the server side. >> >> The second time I run the client it just hangs. >> >> I fixed something in the Pipe#wait method (so update from CVS) but that >> didn''t solve it. >> >> Any ideas? >> > Here is the patch for pipe.rb and server.rb:<snip> Excellent, thanks!> --- win32-pipe/lib/win32/pipe.rb 2008-05-20 14:10:30.000000000 +0900 > +++ pipe.rb 2008-05-20 17:07:53.000000000 +0900 > @@ -62,7 +61,7 @@ > # > def close > DisconnectNamedPipe(@pipe) > - CloseHandle(@pipe) > + # CloseHandle(@pipe) > endI can see why we don''t do this now, but I wonder if we should do this in a finalizer, along with a call to FlushFileBuffers(). All the example code I see closes the handle. Perhaps I''m being overly paranoid about handle leaks, though. I''m also thinking about adding a block form that would automatically ensure a call to Pipe#close. What do you think? Regards, Dan
----- Original Message ----- From: "Daniel Berger" <djberg96 at gmail.com> To: "Development and ideas for win32utils projects" <win32utils-devel at rubyforge.org> Sent: Tuesday, May 20, 2008 8:45 PM Subject: Re: [Win32utils-devel] Asynchronous Pipe::Server problems> Heesob Park wrote: >> 2008/5/20 Daniel Berger <djberg96 at gmail.com>: >>> Heesob Park wrote: >>>> Hi, >>>> >>>> 2008/5/20 Daniel Berger <djberg96 at gmail.com>: >>>>> Hi all, >>>>> >> <snip> >>> However, I''ve botched something else up. I started up the >>> test_async_server.rb program in one terminal, then ran the >>> test_client_async.rb program. The first time it works on the client side: >>> >>> # Client side >>> Connected... >>> write_complete >>> pipe client is running >>> read_complete >>> Got [Ruby rocks!] back from server >>> >>> Though I see nothing on the server side. >>> >>> The second time I run the client it just hangs. >>> >>> I fixed something in the Pipe#wait method (so update from CVS) but that >>> didn''t solve it. >>> >>> Any ideas? >>> >> Here is the patch for pipe.rb and server.rb: > > <snip> > > Excellent, thanks! > >> --- win32-pipe/lib/win32/pipe.rb 2008-05-20 14:10:30.000000000 +0900 >> +++ pipe.rb 2008-05-20 17:07:53.000000000 +0900 >> @@ -62,7 +61,7 @@ >> # >> def close >> DisconnectNamedPipe(@pipe) >> - CloseHandle(@pipe) >> + # CloseHandle(@pipe) >> end > > I can see why we don''t do this now, but I wonder if we should do this in > a finalizer, along with a call to FlushFileBuffers(). All the example > code I see closes the handle. Perhaps I''m being overly paranoid about > handle leaks, though. > > I''m also thinking about adding a block form that would automatically > ensure a call to Pipe#close. > > What do you think? >The problem is due to the reconnect method. The solution is define disconnect as DisconnectNamedPipe ,close as before and modify def reconnect close mainloop end to def reconnect disconnect mainloop end Regards, Park Heesob
Berger, Daniel
2008-May-20 15:06 UTC
[Win32utils-devel] Asynchronous Pipe::Server problems
Hi,> -----Original Message----- > From: win32utils-devel-bounces at rubyforge.org > [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of > Park Heesob > Sent: Tuesday, May 20, 2008 8:25 AM > To: Development and ideas for win32utils projects > Subject: Re: [Win32utils-devel] Asynchronous Pipe::Server problems<snip>> > > > I can see why we don''t do this now, but I wonder if we > should do this in > > a finalizer, along with a call to FlushFileBuffers(). All > the example > > code I see closes the handle. Perhaps I''m being overly > paranoid about > > handle leaks, though. > > > > I''m also thinking about adding a block form that would > automatically > > ensure a call to Pipe#close. > > > > What do you think? > > > The problem is due to the reconnect method. > The solution is define disconnect as DisconnectNamedPipe > ,close as before > and modify > > def reconnect > close > mainloop > end > > to > > def reconnect > disconnect > mainloop > endJust to clarify, we want this in pipe.rb then? def disconnect DisconnectNamedPipe(@pipe) end def close CloseHandle(@pipe) end Thanks, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
Hi, ----- Original Message ----- From: "Berger, Daniel" <Daniel.Berger at qwest.com> To: "Development and ideas for win32utils projects" <win32utils-devel at rubyforge.org> Sent: Wednesday, May 21, 2008 12:06 AM Subject: Re: [Win32utils-devel] Asynchronous Pipe::Server problems> Hi, > >> -----Original Message----- >> From: win32utils-devel-bounces at rubyforge.org >> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of >> Park Heesob >> Sent: Tuesday, May 20, 2008 8:25 AM >> To: Development and ideas for win32utils projects >> Subject: Re: [Win32utils-devel] Asynchronous Pipe::Server problems > > <snip> > >> > >> > I can see why we don''t do this now, but I wonder if we >> should do this in >> > a finalizer, along with a call to FlushFileBuffers(). All >> the example >> > code I see closes the handle. Perhaps I''m being overly >> paranoid about >> > handle leaks, though. >> > >> > I''m also thinking about adding a block form that would >> automatically >> > ensure a call to Pipe#close. >> > >> > What do you think? >> > >> The problem is due to the reconnect method. >> The solution is define disconnect as DisconnectNamedPipe >> ,close as before >> and modify >> >> def reconnect >> close >> mainloop >> end >> >> to >> >> def reconnect >> disconnect >> mainloop >> end > > Just to clarify, we want this in pipe.rb then? >Yes, of course.> def disconnect > DisconnectNamedPipe(@pipe) > end > > def close > CloseHandle(@pipe) > end >close on server.rb could be def close FlushFileBuffers(@pipe) DisconnectNamedPipe(@pipe) CloseHandle(@pipe) end Regards, Park Heesob
Berger, Daniel
2008-May-20 15:41 UTC
[Win32utils-devel] Asynchronous Pipe::Server problems
Hi, <snip>> >> The problem is due to the reconnect method. > >> The solution is define disconnect as DisconnectNamedPipe > >> ,close as before > >> and modify > >> > >> def reconnect > >> close > >> mainloop > >> end > >> > >> to > >> > >> def reconnect > >> disconnect > >> mainloop > >> end > > > > Just to clarify, we want this in pipe.rb then? > > > Yes, of course. > > > def disconnect > > DisconnectNamedPipe(@pipe) > > end > > > > def close > > CloseHandle(@pipe) > > end > > > close on server.rb could be > > def close > FlushFileBuffers(@pipe) > DisconnectNamedPipe(@pipe) > CloseHandle(@pipe) > endOk, I made these changes, and added the begin/ensure for a block form (which you can find in CVS). But, I''ve botched something up in the asynchronous server again (sorry!). I fired up the async server and connected with the async client and this happened. C:\Documents and Settings\djberge\workspace\win32-pipe>ruby -Ilib -Ilib/win32 examples\test_server_async.rb VERSION: 0.2.0 pipe server is running pipe server is running connected read_complete Got [Ruby rocks!] pipe server is running write_complete pipe server is running ./lib/win32/pipe/server.rb:68:in `connect'': The handle is invalid. (Win32::Pipe::Error) from examples/test_server_async.rb:67:in `mainloop'' from examples/test_server_async.rb:97 from ./lib/win32/pipe/server.rb:35:in `initialize'' from examples/test_server_async.rb:96:in `new'' from examples/test_server_async.rb:96 So, somehow the server is calling close unexpectedly. I don''t think it''s the begin/ensure code, because even after removing that I get the same behavior. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
Hi, 2008/5/21 Berger, Daniel <Daniel.Berger at qwest.com>:> > Hi, > > <snip> > >> >> The problem is due to the reconnect method. >> >> The solution is define disconnect as DisconnectNamedPipe >> >> ,close as before >> >> and modify >> >> >> >> def reconnect >> >> close >> >> mainloop >> >> end >> >> >> >> to >> >> >> >> def reconnect >> >> disconnect >> >> mainloop >> >> end >> > >> > Just to clarify, we want this in pipe.rb then? >> > >> Yes, of course. >> >> > def disconnect >> > DisconnectNamedPipe(@pipe) >> > end >> > >> > def close >> > CloseHandle(@pipe) >> > end >> > >> close on server.rb could be >> >> def close >> FlushFileBuffers(@pipe) >> DisconnectNamedPipe(@pipe) >> CloseHandle(@pipe) >> end > > Ok, I made these changes, and added the begin/ensure for a block form > (which you can find in CVS). But, I''ve botched something up in the > asynchronous server again (sorry!). I fired up the async server and > connected with the async client and this happened. > > C:\Documents and Settings\djberge\workspace\win32-pipe>ruby -Ilib > -Ilib/win32 examples\test_server_async.rb > VERSION: 0.2.0 > pipe server is running > pipe server is running > connected > read_complete > Got [Ruby rocks!] > pipe server is running > write_complete > pipe server is running > ./lib/win32/pipe/server.rb:68:in `connect'': The handle is invalid. > (Win32::Pipe::Error) > from examples/test_server_async.rb:67:in `mainloop'' > from examples/test_server_async.rb:97 > from ./lib/win32/pipe/server.rb:35:in `initialize'' > from examples/test_server_async.rb:96:in `new'' > from examples/test_server_async.rb:96 > > So, somehow the server is calling close unexpectedly. I don''t think it''s > the begin/ensure code, because even after removing that I get the same > behavior. >It is because the test_server_async.rb calls close method instead of disconnect. Modify def write_complete puts "write_complete" close @state = CONNECTING_STATE end to def write_complete puts "write_complete" disconnect @state = CONNECTING_STATE end Regards, Park Heesob
Berger, Daniel
2008-May-21 15:50 UTC
[Win32utils-devel] Asynchronous Pipe::Server problems
Hi, <snip>> It is because the test_server_async.rb calls close method > instead of disconnect. > Modify > > def write_complete > puts "write_complete" > close > @state = CONNECTING_STATE > end > > to > > def write_complete > puts "write_complete" > disconnect > @state = CONNECTING_STATE > endOh, silly me. Thanks, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.