From: Brian Hurt <brian.hurt@qlogic.com>
To: Michel Schinz <Michel.Schinz@epfl.ch>
Cc: <caml-list@inria.fr>
Subject: Re: [Caml-list] Re: feature priorities (multithreading)
Date: Thu, 20 Feb 2003 10:26:32 -0600 (CST) [thread overview]
Message-ID: <Pine.LNX.4.33.0302201014080.2037-100000@eagle.ancor.com> (raw)
In-Reply-To: <yorsptpncrff.fsf@lamppc3.epfl.ch>
On Thu, 20 Feb 2003, Michel Schinz wrote:
> I don't agree here, some programs are inherently multi-threaded.
I agree here, but...
>
> Take GUIs for example. Most GUI toolkits today are based on an event
> loop, which waits for events and dispatches them to various
> call-backs. This event loop is nothing more than a poor-man's
> scheduler. It is a poor solution to the problem, though, because this
> scheduler is not preemptive, and this means that your call-backs have
> to execute quickly for the application to be responsive. It also means
> that if your "threads" have a state, this state must be saved
> explicitly between calls.
Each kernel level thread has overhead. On Linux, it's like 8K. So the
difference between spawning one thread or two is irrelevent- but the
difference between spawning one thread and two thousand is important.
Also, you have a dispatching problem. What the OS hands to the
application is a message like "the mouse clicked at location (x, y)". The
application then needs to figure out that location (x, y) just happens to
be in the OK button, and call the correct callback.
>
> All applications which use Posix's "select" function are also
> screaming for threads. When you use "select", you wait for one of
> several events to happen, and when one happens you typically dispatch
> to one event handling function. This is, again, nothing but an ad-hoc
> scheduler.
Again, select has uses- especially if there is going to be a lot of time
between events. As an example, take a look at inetd.
>
> John Reppy's book "Concurrent Programming in ML" contains several
> examples of the usefulness of threads.
>
Threads are most definately usefull- but so is select and event dispatch
loops, in their place. Use the right tool for the job.
Brian
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2003-02-20 16:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-10 18:52 [Caml-list] Request: matrix_init function in Array Brian Hurt
2003-02-10 23:22 ` Pierre Weis
2003-02-11 2:37 ` Chris Hecker
2003-02-13 8:33 ` Pierre Weis
2003-02-13 16:50 ` Chris Hecker
2003-02-13 17:13 ` feature priorities (was Re: [Caml-list] Request: matrix_init function in Array) Ed L Cashin
2003-02-14 17:52 ` brogoff
2003-02-14 20:22 ` rich
2003-02-16 23:07 ` Alessandro Baretta
[not found] ` <Pine.LNX.4.53L.0302170500360.32142@ontil.ihep.su>
2003-02-17 22:27 ` Alessandro Baretta
2003-02-19 9:18 ` [Caml-list] Re: feature priorities (multithreading) James Leifer
2003-02-19 16:46 ` cashin
2003-02-19 17:14 ` Ranjan Bagchi
2003-02-19 17:45 ` Brian Hurt
2003-02-19 18:17 ` Will Benton
2003-02-19 19:26 ` Brian Hurt
2003-02-19 17:25 ` Brian Hurt
2003-02-19 17:26 ` Noel Welsh
2003-02-20 8:00 ` Michel Schinz
2003-02-20 16:26 ` Brian Hurt [this message]
2003-02-13 17:38 ` [Caml-list] Request: matrix_init function in Array Brian Hurt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.33.0302201014080.2037-100000@eagle.ancor.com \
--to=brian.hurt@qlogic.com \
--cc=Michel.Schinz@epfl.ch \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox