Threads or Fibers - which should I use?

Ruby
1

My application will perform a number of tasks. As it is a GUI
application, I want the application to remain responsive to other input
while it’s performing other tasks. A good example of this might be:

A search operation
A compile operation

While the search operation is in effect, no other searches can be
performed until the operation is completed. While a compile operation
is in effect, no other compile option can be completed.

However, a search operation, a compile operation, and other GUI
functionality should still be accessible and responsive.

Give this scenario, which would be better to use - threads or fibers?

2

Alpha B. wrote:

However, a search operation, a compile operation, and other GUI
functionality should still be accessible and responsive.

Give this scenario, which would be better to use - threads or fibers?

Have you considered three processes, GUI, search, and compile, with
communication over drb? That way, the GUI event loop is never encumbered
with other tasks and is robust to failures of those tasks. Plus, you
make use of >1 core.

This might not work well if a huge volume of objects must be shared
between the tasks, but that doesn’t seem likely from your description.

3

Hi Joel.

Let me provide a little more detail.

The logic of the gui itself revolves around building fields that will
eventually be used as web search logic. I’ve written a similar program
in AutoIt which used a lot of C++ core api. The field elements in the
gui are taken and converted into specific string reference, built as a
complete search string and sent to a search engine. This means that
during search functionality I need to make use of sockets.

Brief example:

Say I wanted the program to search for specific stocks across 5 major
stock sites at the same time, pull the data from those sites, compile
the data to see what matches/compares, and display only the relevant
data that has the most recent timestamp. In this particular example, it
would act as a stock ticker.

So, using this example, the Gui will be comprised of the following:

An area to hold stock symbols
An area to hold stock data
An options area for limiting returns by specific criteria
A status bar that’s divided over 3 fields, with one being a built-in
clock.
Etc…

You can probably get a visual idea of what’s going on with this. In
addition, I’m using the following things to develop my gui app.

WxRuby (as my gui library)
DialogBlocks (as my gui designer - xrc builder)
wx_sugar (to setup a frame.rb template for holding all the xrc data)
my_program (which puts the xrc data together along with the listener
events)
etc…

I’m still getting my feet wet with designing ruby gui applications but I
learn fast - always have. I’ve already built at least 10 listener
events and designed a good portion of the gui (being that I already had
a gui created from a former programming lanugage to inherit from).

What I’m trying to do now is setup the transitions of my app. I don’t
want to go through the motions and find that it’s stuck in a loop or
that it appears unresponsive… In AutoIt, sleep events were used like
timers but with loop conditionals attached to them. So, the main gui
would run a large loop and once a listener event was hit, the loop would
exit, the event would be run, and once the event finished, it would
initiate the main gui loop again and setup listening. As you can see
here, this wasn’t multi-threaded and it simply was frustrating to use.

I’m trying to adapt my old program to something better and also allow
for cross-platform accessibility.

Suggestions based off my criteria?

4

Well, after doing a lot of research on this, I’ve come up with the
following:

Fibers would be faster and use less memory for blocking I/O. Threads
are necessary for blocking CPU.

Because my app requires CPU blocking and I/O blocking I could
incorporate both. One of the fibers library I was looking over appears
very solid: (neverblock): GitHub - oldmoe/neverblock: A collection of high level non-blocking IO libraries

I’m still looking over other solutions.

5

On Fri, Jan 22, 2010 at 2:23 AM, Robert K.
[email protected] wrote:

In your case I would start with threads because they are simpler to
use. Â Fibers are really a means of cooperative multitasking and as
such have considerably higher programming overhead. Â Also, either you
have one thread per Fiber or you will not be able to leverage the full
CPU power if you port your app to a Ruby version (say JRuby) which
supports native threads.

It’s worth mentioning that on JRuby, we have to use native threads to
implement Fibers, so they’re not actually lightweight. They’re more
like cooperatively-scheduled child threads. I’d recommend threads as
well if the intent is to actually have parallel execution.

  • Charlie
6

2010/1/22 Alpha B. [email protected]:

I’m still looking over other solutions.
In your case I would start with threads because they are simpler to
use. Fibers are really a means of cooperative multitasking and as
such have considerably higher programming overhead. Also, either you
have one thread per Fiber or you will not be able to leverage the full
CPU power if you port your app to a Ruby version (say JRuby) which
supports native threads.

My 0.02EUR.

Kind regards

robert