Non-blocking KitchenSink


#1

I am a recent convert and I am very impressed by the productivity gains
from Ruby.

I would like to basically throw the kitchen sink into the Ruby scripts I
am creating.

I need to use Webrick, SOAP client, SOAP server, DRb, REXML, and Log4r.
However, when I attempt to use the SOAP server and client in the same
script, the SOAP client call blocks the script.

Is it possible to use Webrick, SOAP client, and SOAP server code all in
the same script without blocking? I tried different threads for the
SOAP server and SOAP client, but that did not prevent blocking.

I would like to be able to create daemons respond to SOAP messages and
that are also tiny web servers that allow me to view their logs and near
real-time status from a web page.

Any assistance will be greatly appreciated.

Thanks,

hackdaddy


#2

On Mar 3, 2006, at 5:46 PM, Aaron Becker wrote:

Is it possible to use Webrick, SOAP client, and SOAP server code
all in
the same script without blocking? I tried different threads for the
SOAP server and SOAP client, but that did not prevent blocking.

Ruby’s threads are in-process any blocking call blocks the whole
process. So I suppose the answer is no. However, what you can try is
using multiple processes and coordinating them with Drb.


#3

Logan C. wrote:

On Mar 3, 2006, at 5:46 PM, Aaron Becker wrote:

Is it possible to use Webrick, SOAP client, and SOAP server code
all in
the same script without blocking? I tried different threads for the
SOAP server and SOAP client, but that did not prevent blocking.

Ruby’s threads are in-process any blocking call blocks the whole
process. So I suppose the answer is no. However, what you can try is
using multiple processes and coordinating them with Drb.

Thanks for the reply!

I did manage to get DRb and Webrick working in the same script. I’m
using HTTPServlet::FileHandler to allow the browsing of logs, status,
etc.

This Ruby language is so powerful my immediate temptation is to over
design everything. Well, I guess it’s like test driving a new car. I
want to see how far I can push it.

Since I have Webrick already running in a thread, would it be possible
to receive SOAP messages on the same port that it is using for browsing
directories?

Thanks,

hackdaddy


#4

Aaron Becker wrote:

using multiple processes and coordinating them with Drb.
want to see how far I can push it.

Since I have Webrick already running in a thread, would it be possible
to receive SOAP messages on the same port that it is using for
browsing directories?

Never done this myself with this setup. Since
Webrick is pretty flexible you should be able to define a request
handler
that delegates certain requests to the SOAP handling stuff. The easiest
is probably to define a common prefix for all SOAP requests.

Kind regards

robert

#5

On Mar 6, 2006, at 8:36 PM, Eric H. wrote:

Not entirely true. Calls to C code other than socket operations
block the whole process. read and select and accept only block the
thread that calls that method since the core libraries wrap all
that up for you.

Cool I did not know that.


#6

Quoting Logan C. removed_email_address@domain.invalid:

On Mar 6, 2006, at 8:36 PM, Eric H. wrote:

read and select and accept only block the thread that calls
that method since the core libraries wrap all that up for you.

Cool I did not know that.

Note that your C code needs to call the rb_* versions of select and
read to get the benefit.

-mental


#7

On Mar 3, 2006, at 3:09 PM, Logan C. wrote:

On Mar 3, 2006, at 5:46 PM, Aaron Becker wrote:

Is it possible to use Webrick, SOAP client, and SOAP server code
all in
the same script without blocking? I tried different threads for the
SOAP server and SOAP client, but that did not prevent blocking.

Ruby’s threads are in-process any blocking call blocks the whole
process. So I suppose the answer is no. However, what you can try
is using multiple processes and coordinating them with Drb.

Not entirely true. Calls to C code other than socket operations
block the whole process. read and select and accept only block the
thread that calls that method since the core libraries wrap all that
up for you.


Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com