Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Hot code replacement
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Donn Cave  
View profile  
 More options Mar 7 2003, 11:40 pm
Newsgroups: comp.lang.functional
From: "Donn Cave" <d...@drizzle.com>
Date: Sat, 08 Mar 2003 04:40:56 -0000
Local: Fri, Mar 7 2003 11:40 pm
Subject: Re: Hot code replacement
Quoth step...@dino.dnsalias.com (Stephen J. Bevan):
...
| Then I think we are talking past each other.

I thought I noticed that a couple rounds back.

| ... What they do internally
| is of prime importance since if they don't use OS threads it is a fair
| bet that any attempt to link in a library that does use OS threads
| will not interact very well.

What is important in the end is whether the implementation
supports execution in multiple separate threads.  If it does
(e.g., ocaml), the rest can be worked out.  Language level
concurrency features are not directly relevant, and it's
conceivable that a language might offer an internal pseudo
concurrency feature and also be viable in a threaded application.
(I've seen this with "stackless" Python, and there is apparently
a potential development in this direction for GHC.)

|> I'm saying that on comp.lang.limbo, they would say "you can do that"
|> - Limbo's concurrency primitives create OS threads and run in them
|> in a way that is exposed to the programmer.  Of course it appears to
|> have the luxury of a platform that supplies some other useful
|> features (channels) for dealing with OS threads, so you get the best
|> of both - its concurrency is real and also practically useful.  
|
| The Limbo is available under Inferno which in turn is available as a
| native OS or hosted on a variety of OSes.  I've no idea if they all
| use OS threads or not.  If they do that solves one set of problems.
| However, for some hosted platforms it rules out using threads for
| other problems e.g. the thread per connection approach which would
| work fine under Erlang (or at least to the point where file-descriptor
| limits are the problem not threads) or other systems which do not use
| an OS thread per language thread.  Note I'm not arguing against OS
| threads here, just pointing out that they are not an automatic win and
| there are good reasons for some languages/implementations not using
| them if those languages/implementations are targetting a certain class
| of problems.

I think I can go out on a limb here and say that Inferno certainly
does use OS threads (where Inferno is the OS in question.)  On the
other hand, I could only guess that it (always) implements threading
internally, so in some sense Erlang might be compared to Inferno plus
Limbo.

        Donn Cave, d...@drizzle.com


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.