Re: [xiki] xiki not working under windows because fork is unimplemented. (#27)

[Craig Muth]

Including xi...@googlegroups.com in the thread...

> As for other means of communication, named pipes may be good and pretty
> cross platform (similar tech, different implementation). They should be
> secured like above by default, see
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa365600(v=vs.85).aspx

Cool! This seems like it could work interchangeably with how the
'xiki' command talks to the daemon. Can you paste a simple hello
world working example that does this?

1. How to creates the pipe file
2. Code that writes to it
3. Code that reads from it

Also, what's the latest best practice for testing out Windows stuff
from a mac?

If it's cross-platform-ish, maybe I could implement it on the Mac, and
expect it to just work on Windows?

--Craig

[Craig Muth]

> As for other means of communication, named pipes may be good

According to that page, Xiki already is using named pipes (search the
Xiki codebase for "mkfifo" and you'll see that's what it's doing).

> A sample could be found on
> http://stackoverflow.com/questions/9796258/how-do-i-block-on-reading-a-named-pipe-in-ruby

There are several samples on that page, which one do you have in mind?
The one that uses "mkfifo" looks like it requires cygwin. If you
have cygwin I think the current xiki implementation might work
(possibly with some tweaks _____pull request). But several people
have given the __no cygwin__

There's a lot of code on the
http://stackoverflow.com/questions/9796258/how-do-i-block-on-reading-a-named-pipe-in-ruby
page between the two samples starting with...

> module PipeLogger
> ...

...and...

> require 'rubygems'
> require 'win32/pipe'
> include Win32
> ...

Is all of that stuff in .setup_pipe really necessary?

Perhaps http://rubydoc.info/gems/win32-pipe/0.3.0/file/README is
better to look at, and has some of the lower-level stuff abstracted
out? It doesn't appear to be cross-platform. But I guess having a
XikiWindowsAdapter-ish class that just does it differently wouldn't be
too bad.

Does the example on the above win32-pipe readme block users from
reading and writing to the pipe that don't have permission for the
pipe, do you know?

--Craig








> As for testing, a VM should be fine. If not, I'm sure people can test it,
> including myself.
>
> —
> Reply to this email directly or view it on GitHub.

[Craig Muth]

Dang, those "________" lines were my way of reminding myself to finish
those sentences before sending. Obviously that didn't work :) I
meant to say...

If you have cygwin I think the current xiki implementation might work

(possibly with some tweaks from
https://github.com/trogdoro/xiki/pull/32). But several Windows people
have given the feedback that having cygwin as a Xiki dependency would
make them unhappy.

> @trogdoro There are two answer, I had in mind the one with 2 (top) votes.
> I don't use Cygwin usually

His description includes "Note that I'm using mkfifo from cygwin".

> However first
> my issue is with fork() not implemented (it's not on Windows).

Ah, that's happening in the Daemons gem, which Xiki uses to start up a
Xiki instance so subsequent calls (connected to via pipe) will be
fast.

Any of you Windows people know of a Daemons gem alternative that works
on Windows?

> Does the example on the above win32-pipe readme block users from
> reading and writing to the pipe that don't have permission for the
> pipe, do you know?

If anyone knows this, I'd love to hear the answer.

--Craig

[Craig Muth]

Cool!

Will this deny clients who try to connect and don't have sufficient privileges?

> # TODO: Wait for mutex or find a better way to wait for the process to be ready.
> sleep(0.5)

I wonder if a better way to wait was found. Half a second delay is
way to slow. The xiki command using unix pipes completes in under .03
seconds.

Have you experimented with having smalle sleep times? I'm guessing it
might start hogging the cpu if you make the sleep time down in that
range?

Anyone know of a Windows equivalent to the Daemons gem? It lets you
start, stop, restart and get the status of a process.

--Craig


On Wed, Mar 13, 2013 at 4:55 AM, Werner Beroux <notifi...@github.com> wrote:
>
> Code:
>
> # gem install win32-pipe
> # gem install win32-mutex
> require 'win32/mutex'
> require 'rbconfig'
> require 'win32/pipe'
> include Win32
>
> $stdout.sync = true
>
> THIS_FILE = File.expand_path(__FILE__)
> RUBY = File.join(Config::CONFIG['bindir'], Config::CONFIG['ruby_install_name'])
>
> def child_main(source)
> puts "[child] Started \"#{source}\""
> # Single instance (could also use a temporary file but this is a better way on Windows)
> Win32::Mutex.new(false, 'some_unique_id') do |mutex|
>
> while true do
> pipe_server = Pipe::Server.new("foo_pipe")
> pipe_server.connect
> data = pipe_server.read
> puts "[child] Got #{data} from client"
> pipe_server.close
> end
>
> mutex.release
> end
> puts "[child] Terminated"
> end
>
> if $PROGRAM_NAME == __FILE__
> cmd = %Q<#{RUBY} -r#{THIS_FILE} -e 'child_main("ip")'>
> begin
> Win32::Mutex.open('some_unique_id') do |mutex|
> mutex.close
> end
> puts "[parent] Process already running"
> rescue #Win32::Mutex::Error => e
> puts "[parent] Starting process"
> Process.spawn(cmd);
> end
>
> # TODO: Wait for mutex or find a better way to wait for the process to be ready.
> sleep(0.5)
>
> pipe_client = Pipe::Client.new("foo_pipe")
> pipe_client.write("Hello World")
> pipe_client.close
> end
>
> Execution:
>
> $ ruby test.rb
> [parent] Starting process
> [child] Started "ip"
> [child] Got ["Hello World"] from client
>
> $ ruby test.rb
> [parent] Process already running
> [child] Got ["Hello World"] from client