James Tucker
5/27/2007 6:12:00 AM
Someone else was talking about this kind of problem the other day in
#ruby-lang.
Another posted an elegant solution to the problem (which incidentally
was refused as it was another process), however:
#!ruby
raise 'You need to install win32/process' unless require 'win32/process'
if RUBY_PLATFORM.include? 'mswin32'
# parent forks off and dies, leaving child as daemon
exit 0 if !fork.nil?
# daemon code starts here
require 'drb/drb'
require 'thread'
require 'server'
$SAFE = 1 # disable eval() and friends
DRb.start_service("druby://:2020", Server.new)
puts DRb.uri
DRb.thread.join
Francis Cianfrocca wrote:
> On 5/26/07, braver <deliverable@gmail.com> wrote:
>>
>> On May 26, 2:24 pm, Robert Klemme <shortcut...@googlemail.com> wrote:
>> > I'd consider using Marshal.
>>
>> That's just plain serialization, isn't it? I've seen that and
>> Madelaine; but my wish is to keep the objects in memory without the
>> need to dump/reload it, however fast. (That would be a last resort.)
>>
>> The question is, can we keep an object in memory in one thread, and
>> explore/change it from another? In the worst case, we can probably
>> quickly dump an object into a memory region and reload it back via
>> Marshal -- I guess a crude solution is forming here, using shared
>> memory or RAM disk -- have to see what's there for macs... But still
>> I wonder what folks think in terms of all kinds of RAM persistence in
>> ruby solutions.
>
>
>
>
> Aren't you overengineering a little? You want to amortize a ten-second
> startup cost over a (presumably) large number of operations against some
> dataset. But you keep talking about threads. That tells me that your
> process
> will run for a long time and will know all the operations it has to
> execute
> upfront. In that case, forget about threads and just serialize your
> operations. Your life will be much simpler.
>
> But on the other hand, you talk about shared memory and about not
> wanting to
> write a client/server application. That suggests that you're thinking of
> keeping this dataset around and having other PROCESSES sent requests
> to it
> at arbitrary times. In that case, don't use threads either, or
> shared-memory
> for that matter. Life is too short to debug all that stuff. Write
> yourself a
> little client-server application and be done with it. If you don't
> want to
> deal with the network programming, use EventMachine.
>