Forum: Ruby ruby Thread in CGI application?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
A70b7da5a3a712e800100e61ef8d8917?d=identicon&s=25 ako... (Guest)
on 2006-01-12 05:04
(Received via mailing list)
Hello,

i heard that ruby's Thread is not a native system thread but is
implemented in the interpreter itself. is that true? does this mean
that is is lighter than native threads? does anyone know if
Thread.start on every web request in my CGI application would severely
reduce my web server's scalability?

thanks
konstantin
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-01-12 05:20
(Received via mailing list)
ako... wrote:

>
>
>
>
Err. CGI already does start a new process to process each request,
spinning off a worker thread is superfluous.

David Vallner
A70b7da5a3a712e800100e61ef8d8917?d=identicon&s=25 ako... (Guest)
on 2006-01-12 06:20
(Received via mailing list)
right. i mean FastCGI. a separate thread might be needed to execute a
code fragment with a safety level which is different from the safety
level of the rest of the CGI script.

konstantin
8c43ed7f065406bf171c0f3eb32cf615?d=identicon&s=25 Zed Shaw (Guest)
on 2006-01-12 11:51
(Received via mailing list)
Hi konstantin,

As the author of SCGI (http://www.zedshaw.com/projects/scgi_rails/) I
can tell you that this is possible, but you have to be careful not to
step on anyone's toes.  As David Vallner mentioned previously it's
pretty pointless in a plain CGI.  In FastCGI, SCGI, or mod_ruby it's
viable but tricky.

Ruby threads are implemented using a select IO loop, so they're
fairly lightweight.  You can also use Ruby's fork to give yourself
N:M threading if you want multiple processors to handle more requests
or if you want more than select can handle.  Generally the Ruby
threading model is good but is a little weird in places.

 From the SCGI perspective you want to avoid the following:

1)  Leaving IO objects open after you're done with your request.  It
will eventually get cleaned out (and I'm working on cleaning more),
but it's a total waste.  Be good and keep your house clean.
2)  Putting stuff in the thread local store.  This is generally OK in
your own threads, but again this stuff doesn't go away until the GC
collects it which in Ruby means quite a while.  If you seem to get
weird leaks then investigate this.
3)  Wildly making calls to Rails functions inside the threads.  Rails
isn't very thread safe, in fact I'd say it's not thread safe at all.
If you're running multiple threads that try to hit AR for example,
then you'll get tons of DB connections since AR by default uses
thread local storage for it's DB connection pooling.  Other examples
are how modules get loaded--if a model or controller isn't loaded
when your thread fires off and you try to use it then Ruby throws a fit.
4)  Expecting threads to solve problems in your workflow design.
Typically I see people who want to use threads to offload some
processing in the background so that the user can continue using the
web app while their big work is being done.  What invariably ends up
happening is the background thread doesn't run reliably and causes
major havoc with the rest of the application's processing.  This is
especially true if you use fork or exec.  A better approach is to
either redesign the workflow to not need this or write a separate DRb
server that runs stand-alone and processes these requests.  The DRb
solution is also really powerful since you can then offload the
processing to tons of other machines if you need.

Anyway, good luck on it.  Feel free to hit me up if you have thread
problems.

Zed A. Shaw
http://www.zedshaw.com/
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-01-12 12:26
(Received via mailing list)
That said, it might also be questionable just how useful it is to create
request processor threads even in FastCGI / SCGI, because that's
precisely
the purpose of those. You're very likely better off tweaking the
settings
of those to get what you might want done.

Now, a longer rant for the sake of completion: Using worker threads is
more viable, but that is only useful in certain scenarios, for example:

1. In interactive long-running programs, where you want to maintain a
responsive user interface while doing background work. This is _very_
rarely the case with a web application, because you usually need to
process each request in finite (and rather short) time.

2. On a multiple CPU system, where algorithms used in processing the
request might benefit from parallelism running multiple processors.
Though
then again, you probably wouldn't do CPU-intensive operations as these
algorithms tend to be in Ruby anyway. As more realistic examples,
asynchronous database / remote calls come to mind if you want to
implement
your own timeout policy to those to handle badly written third party
libraries graciously to prevent your application from hanging up.

Unless you have due cause to do so, do avoid multithreaded programming
or
keep it very simple, there's just way too many ways to shoot yourself in
the foot.

David Vallner
E555e7c34196967444a47a96395a23ab?d=identicon&s=25 Stefan Kaes (Guest)
on 2006-01-14 06:03
(Received via mailing list)
David Vallner wrote:
> 2. On a multiple CPU system, where algorithms used in processing the
> request might benefit from parallelism running multiple processors.
> Though then again, you probably wouldn't do CPU-intensive operations
> as these algorithms tend to be in Ruby anyway. As more realistic
> examples, asynchronous database / remote calls come to mind if you
> want to implement your own timeout policy to those to handle badly
> written third party libraries graciously to prevent your application
> from hanging up.
Currently you won't benefit from multiple CPUs as Ruby doesn't use
native threads.

-- stefan
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-01-14 07:31
(Received via mailing list)
On Sat, 14 Jan 2006 06:02:13 +0100, Stefan Kaes <skaes@gmx.net> wrote:

> native threads.
>
> -- stefan
>


Slipped my mind. I was talking in general anyway. And doesn't the
pthread
binding let you use native threads? (Didn't really do anything with it
himself)

David Vallner
E555e7c34196967444a47a96395a23ab?d=identicon&s=25 Stefan Kaes (Guest)
on 2006-01-14 07:45
(Received via mailing list)
David Vallner wrote:
>>> from hanging up.
>
> David Vallner
>
>
I don't know enough about Ruby's pthread support to have an informed
opinion on this question :-(

-- stefan
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-01-14 11:10
(Received via mailing list)
2006/1/14, Stefan Kaes <skaes@gmx.net>:
> David Vallner wrote:
> > Slipped my mind. I was talking in general anyway. And doesn't the
> > pthread binding let you use native threads? (Didn't really do anything
> > with it himself)
> >
> I don't know enough about Ruby's pthread support to have an informed
> opinion on this question :-(

AFAIK there is no support for any native threading in standard Ruby
1.x.  The interpreter just isn't designed for this. For web apps
Ruby's threading might be sufficient in the general case because there
is a lot IO and multiplexing on IO should work find.

Btw, native thread support for me is one of the key improvements of Ruby
2.

Kind regards

robert
This topic is locked and can not be replied to.