concurrency in IO

On Thu, 26 Jul 2007 05:03:50 -0400
Miles Fidelman < mfidelman%40meetinghouse.net">mfidelmanmeetinghouse.net>; wrote:

> Actually, the comment re. Erlang being different is from David Fayram,
> in response to a question I asked.
&gt;
> Miles

Ah, sorry for the confusion. I came in mid-conversation so I don't have the full history.

- John

On 26-Jul-07, at 4:27 AM, John Nowak wrote:

> On Wed, 25 Jul 2007 20:18:56 -0400
&gt; Jeremy Tregunna < jtregunna%40blurgle.ca">jtregunnablurgle.ca> wrote:
&gt;
>&gt; On 25-Jul-07, at 3:28 PM, David Fayram wrote:
&gt;>
&gt;>>
>>> On Jul 25, 2007, at 11:45 AM, Miles Fidelman
>>&gt;
>&gt;> Its approach is really different from io's mostly on the lack of
>&gt;> global state (which Io must have unless it changes its inheritance
>>;> scheme to be more like Self's), its real underlying native threads,
>>&gt; and its pure arbitrary-data asynch message passing.
>>
>> Well, Io has no notion of globals, only locals. What you're seeing is
>&gt; due to the fact that Io only has one Lobby. I would stipulate that it
>&gt; has "shared" state in some corner cases, but state is local to the
>> object its being called on 99 times out of 100.
>;
> Is this really true? You're tracing back to Object for all sorts of
> things. Every if(), every setSlot(), every updateSlot(), every
> method(), etc. I would think the 99% figure you give is probably
> closer to 10%. If it is 99%, I'm wasting a lot of time with Courier
> by having every object have its own persistent, total environment.
> I think Miles is correct in that Erlang is really quite different
> from Io.

Note I'm talking about state, not behaviour.

> - John

--
jer

On 7/26/07, Jeremy Tregunna < jtregunna%40blurgle.ca">jtregunnablurgle.ca> wrote:
&gt; Note I'm talking about state, not behaviour.

Even behavior is local -- as Jer was so fond of pointing out to me in
IRC, state == behavior in a slot-based language like Io.

Every object inherits from Object -- sure. But that does not make it
a "global" value in the C sense of the term.

Io> xObject := Object clone do(hiThere := method(&quot;hello world!&quot; println))
==> Object_0x81afd98:
hiThere = method(...)

Io&gt; Lobby Protos Core Object = xObject
==> Object_0x81afd98:
hiThere = method(...)

Io&gt; Lobby Protos Core
==&gt; Object_0x805b568:
....
Notifier = Notifier_0x8094d10
Number = 0
Object = Object_0x81afd98 <==--- Notice the update
OperatorTable = OperatorTable_0x80b3210
Path = Path_0x81d2808
.....
true = true
vector = method(...)

Io&gt; hgWells := Object clone
==> Object_0x822bff0:

Io> hgWells hiThere
hello world!
==> hello world!

So, now, all new instances of Object are now really xObject -- the old
Object instance isn't used for new objects anymore. Within xObject,
we are free to swap the meaning of the true- and false-blocks in if(),
or alter while() to perform something really bizarre. Etc.

In fact, the only way to address the old Object is to follow the
inheritance chain of a pre-existing object instantiated while the old
Object was still the ultimate base object. That hardly counts as
being global.

--
Samuel A. Falvo II

•  2
  New Members

• Computer telephony
• Portable computer
• Basic programming language
• C programming language
• Computer programming languages

On Jul 26, 2007, at 5:44 AM, Jeremy Tregunna < jtregunnablurgle.ca">jtregunnablurgle.ca> wrote:

On 26-Jul-07, at 4:27 AM, John Nowak wrote:

> On Wed, 25 Jul 2007 20:18:56 -0400
&gt; Jeremy Tregunna < jtregunna%40blurgle.ca">jtregunnablurgle.ca> wrote:
&gt;
>&gt; On 25-Jul-07, at 3:28 PM, David Fayram wrote:
&gt;>
&gt;>>
>>> On Jul 25, 2007, at 11:45 AM, Miles Fidelman
>>&gt;
>&gt;> Its approach is really different from io's mostly on the lack of
>&gt;> global state (which Io must have unless it changes its inheritance
>>;> scheme to be more like Self's), its real underlying native threads,
>>&gt; and its pure arbitrary-data asynch message passing.
>>
>> Well, Io has no notion of globals, only locals. What you're seeing is
>&gt; due to the fact that Io only has one Lobby. I would stipulate that it
>&gt; has "shared" state in some corner cases, but state is local to the
>> object its being called on 99 times out of 100.
>;
> Is this really true? You're tracing back to Object for all sorts of
> things. Every if(), every setSlot(), every updateSlot(), every
> method(), etc. I would think the 99% figure you give is probably
> closer to 10%. If it is 99%, I'm wasting a lot of time with Courier
> by having every object have its own persistent, total environment.
> I think Miles is correct in that Erlang is really quite different
> from Io.

Note I'm talking about state, not behaviour.

> - John

--
jer

•  2
  New Members

• Computer telephony
• Portable computer
• Basic programming language
• C programming language
• Computer programming languages

On Jul 25, 2007, at 5:13 PM, Steve Dekorte < stevedekorte.com">stevedekorte.com> wrote:

On Jul 25, 2007, at 12:28 PM, David Fayram wrote:
&gt; I've worked with erlang pretty extensively, and concurrency is one
> area where Erlang is pretty much unparalleled. Threads are pre-emptive
> and executed in native context. Its reall y quite inspiring.
>
&gt; The general idea is that on VM start, Erlang sets up N execution
> threads, where N is the number of cores on the device. Erlang
&gt; processes (which all share no state) execute on top of one of these
&gt; contexts.
>
&gt; The programmer doesn't consider this, however. The runtime abstracts
> all this, just providing the developer with cheap "process" creation.
>
&gt; Its approach is really different from io's mostly on the lack of
> global state (which Io must have unless it changes its inheritance
> scheme to be more like Self's), its real underlying native threads,
> and its pure arbitrary-data asynch message passing.

Erlang is based on communicating processes which can be implemented
in any language. Erlang's value seems to be in putting this in a
package that makes it easier to use and more efficient for certain uses.

That said, I would be interested to see how one would go about
implementing an application that depends heavily on object
inheritance and code reuse (such as a GUI framework) in such a
system. If one has to end up implementing complex synchronization
code or running into complexity and overhead wrt communication then
it might be worth considering the trade-offs involved with such
solutions and whether they make sense for your application.

On Thu, 26 Jul 2007 15:21:21 -0400
Jeremy Tregunna < jtregunna%40blurgle.ca">jtregunnablurgle.ca> wrote:

> It's literally one extra bit and some extra logic code in Io to
> support locking slots from being updated,

Do you mean locking for every single read and write? That might technically work, but it wouldn't be much fun to program with (or well-performing in any sense).

> and/or one extra bit to support immutable objects.

That wouldn't help much either unless nearly every object was immutable, which would defeat the point of using Io (and would also perform horribly with the current implementation).

- John

On 7/26/07, David Fayram < dfayram%40gmail.com">dfayramgmail.com> wrote:
&gt; Steve, isn't Io a poor candidate for this kind of system since the behavior of objects is so mutable? Erlang allows code updating, but only in a very incremental and manual process. An erlang process in a responder loop won't update its code unless you explicitly make a non-local call to the module.

Let's not forget that Erlang is a functional programming language, not
an OO language. This will influence design decisions, not only about
the language itself, but also the runtime, and what is possible at the
application level too.

--
Samuel A. Falvo II

•  2
  New Members

• Computer telephony
• Portable computer
• Basic programming language
• C programming language
• Computer programming languages

On Thu, 26 Jul 2007 13:16:45 -0700
&quot;Samuel A. Falvo II" < sam.falvo%40gmail.com">sam.falvogmail.com> wrote:

> On 7/26/07, David Fayram < dfayram%40gmail.com">dfayramgmail.com> wrote:
&gt; > Steve, isn't Io a poor candidate for this kind of system since the
> > behavior of objects is so mutable? Erlang allows code updating, but
> > only in a very incremental and manual process. An erlang process in
> > a responder loop won't update its code unless you explicitly make a
> > non-local call to the module.
>
> Let's not forget that Erlang is a functional programming language, not
> an OO language. This will influence design decisions, not only about
&gt; the language itself, but also the runtime, and what is possible at the
> application level too.

Yes, that's the point. Parallelism in the Erlang sense isn't possible in Io due to the prevalence of mutation and the extreme amount of shared state due to differential inheritance.

- John

On Jul 26, 2007, at 12:45 PM, David Fayram wrote:
&gt; Steve, isn't Io a poor candidate for this kind of system since the
> behavior of objects is so mutable? Erlang allows code updating, but
> only in a very incremental and manual process. An erlang process in
> a responder loop won't update its code unless you explicitly make a
> non-local call to the module.

I'm not sure how mutation is related. AFAICS, the only important bits
for using lots of communicating processes is that the process size be
small and the communication overhead be low.

Immutable objects such as symbols can be handy for passing references
instead of copying data to other processes (lowering communication
overhead), but that's just an optimization and Io already has
immutable symbols.

Erlang's process stacks are more lightweight than Io's coroutines
(100s of bytes vs a few K) but this isn't much help if the state
associated with a processes is much larger than their stacks, which
is probably the case. However, Erlang can switch between processes
faster and it's biggest performance advantage is probably it's lower
level semantics (within a process, the semantics aren't based on
dynamic message sends). But when it comes to semantics, you get what
performance you pay for with development time.

- Steve