Self-interest April 1995

self-interest@lists.selflanguage.org

7 participants
10 discussions

Re:Re: Support for native OS threads ?
by Jecel Mattos de Assumpcao Jr. 29 Apr '95

29 Apr '95

On Wed, 26 Apr 95 10:03:17 METDST Reto Kramer <kramer(a)al.esec.ch> wrote: > [ lots of interesting stuff deleted ] > > The notion of active vs. passive objects has proved to be an advantage in > our project because the application developers are shielded from low level > process/semaphore/queue related synchronization issues and can work on the > a higher abstraction level provided by asynchronous/synchronous/future and > balking message passing sematics. That is what I think too. BTW, what is a "balking" message send? > - Is there any attempt to bring the notion of active/passive objects, and > multiple message passing sematics into self ? I am working on it, but I don't think it will be ready in time to be of use to you. My ( mythical ) TinySelf interpreter has only active objects. Every message send returns a future object immediately as the result, while the message gets queued at the receiver for later processing ( if it is already doing something else, each object executes a single method at a time ). If you try to send a message to the future object, however, you block. When the receiver finishes executing the message and returns the real answer, the future "become:"s that answer and unblocks any waiting objects ( threads ). In code like "x mess1 + y mess2", mess1 will block while mess2 won't ( it will inside the + method, of course, but that doesn't matter here ). So messages are synchronous or asynchronous depending on how they are used, no matter what the sender or the receiver. This might prove to be *too* simple for serious applications, but I hope it will be enough. Of course, the way I have described it so far this model would make recursive methods deadlock and an object like the number 2 would be a serious bottleneck in the system. But I won't go into these details here. > - Is it considered to be a good idea to build these features into the language > or should they always be provided by an add on system (if so, things like > the CLOS "around/before/after" functions are useful and make the > doesNotUnderstand trick obsolete in certain cases). In some systems this might be done using some metaobject protocol, but I feel that Self's "message passing at the bottom" approach makes it better to have a built-in concurrency model. Regards, -- Jecel Mattos de Assumpcao Jr Laboratorio de Sistemas Integraveis - University of Sao Paulo - Brazil jecel(a)lsi.usp.br http://www.lsi.usp.br/~jecel/jecel.html

1 0

Re:Re: Support for native OS threads ?
by Reto Kramer 29 Apr '95

29 Apr '95

> FROM: Ole Agesen ON: Apr 25 '95 at 1:50 pm > > Date: Tue, 25 Apr 1995 13:50:31 -0700 > To: kramer(a)al.esec.ch > Subject: Re: Support for native OS threads ? > Cc: self-interest(a)otis.stanford.edu > Status: RO > > > From: Reto Kramer <kramer(a)al.esec.ch> > > Subject: Support for native OS threads ? > > Date: Tue, 25 Apr 95 13:19:37 METDST > > > > Does the current self system support > > native OS threads ? > > > > (At the moment I am working with ParcPlace > > Smalltalk and I have about 250 Processes > > around. It would be nice, if they were > > on the level of the OS as opposed to the > > VM and bytecodes, as they are at the moment) > > > > Reto > > ---- > > The Self threads are OS independent like Smalltalk's (implemented with > timer interrupts in the Self VM and Self code). Would you mind telling > me why you prefer OS level threads, btw? (Not that I disagree with you, > I'd just like to hear your reasons - it sounds like you have more massive > experience with processes than most people). > > Thanks > Ole Let me give you a brief description of our background to explain our need for a lot of threads (here I understand the Smalltalk Process objects as threads too). I do this beeing aware of the fact that the subject might be considered to be more appropriate for another newsgroup (design/general OO). However I am looking for language support for out design approach and self is a candidate ! We are developing a CIM system closely related to the SEMATECH framework model. Our soft-realtime system is beeing implemented in VisualWorks. Our design describes the system as asynchronous which contributes to the fact that we have a lot of objects that execute methods under "their own processor time". E.g. each piece of production machinery is an active object, whereas the material flowing through the CIM system is mostly passive. The notion of active and passive objects allows us to use message passing sematics like: synchronous (default for passive objects), asynchronous (default for active objects), future and balking. By default the receiver determines the execution mode of a message sent to it. However the sender may override this default. E.g. An active object can be queried for a result in a synchronous way, overriding the asynchronous default behaviour of the receiver. Our approach uses the doesNotUnderstand trick and uses ideas from the Actalk Smalltalk extension. As in Actalk, active objects wrapped with a "doesNotUnderstand:-shell" so we can get our hands on the messages. By default messages get stored in a queue. The thread that is associated with the active object reads from the queue and evaluates the message under its processor time. Thus the message sent is not evaluated in the sender's thread. N.B. Exception handling in this environment is a very interesting subject. The advantages I expect from "native-OS-threads" would be: - lower wake-up latency (today the entire image must be swapped in, if a thread wakes up) - non blocking OS calls (today the entire VM block when doing a C call and thus no threads do not get scheduled or executed during that time) The need for a lot of threads (and native OS thread support) is only an artifact of the idea to model and implement our system using the high level abstraction of active and passive objects ! The notion of active vs. passive objects has proved to be an advantage in our project because the application developers are shielded from low level process/semaphore/queue related synchronization issues and can work on the a higher abstraction level provided by asynchronous/synchronous/future and balking message passing sematics. - Is there any attempt to bring the notion of active/passive objects, and multiple message passing sematics into self ? - Is it considered to be a good idea to build these features into the language or should they always be provided by an add on system (if so, things like the CLOS "around/before/after" functions are useful and make the doesNotUnderstand trick obsolete in certain cases). Looking forward to hearing from you ! Reto

2 1

Support for native OS threads ?
by Reto Kramer 27 Apr '95

27 Apr '95

Does the current self system support native OS threads ? (At the moment I am working with ParcPlace Smalltalk and I have about 250 Processes around. It would be nice, if they were on the level of the OS as opposed to the VM and bytecodes, as they are at the moment) Reto ---- ESEC SA Reto Kramer Autoline R&D Hinterbergstr. 32 CH-6330 Cham Switzerland email: {kramer(a)acm.org, reto.kramer(a)al.esec.ch} tel (direct): +41 42 44 52 84 fax : +41 42 41 64 84

2 1

Re: Support for native OS threads ?
by David Ungar 26 Apr '95

26 Apr '95

Sorry, but our threads, like Smalltalk's do not go down to the OS. On the other hand, our scheduler is above the line, not below, where you can change it to your heart's delight. - Dave ------ From: Reto Kramer, Tue, Apr 25, 1995 ------ Does the current self system support native OS threads ? (At the moment I am working with ParcPlace Smalltalk and I have about 250 Processes around. It would be nice, if they were on the level of the OS as opposed to the VM and bytecodes, as they are at the moment) Reto ---- ESEC SA Reto Kramer Autoline R&D Hinterbergstr. 32 CH-6330 Cham Switzerland email: {kramer(a)acm.org, reto.kramer(a)al.esec.ch} tel (direct): +41 42 44 52 84 fax : +41 42 41 64 84

1 0

Re: Self demos
by Jecel Mattos de Assumpcao Jr. 08 Apr '95

08 Apr '95

On Fri, 7 Apr 1995 09:28:16 -0700 (PDT), Tilak Ravi <tilak(a)ecst.csuchico.edu> wrote: > > Yes! that is great having a m/c where we could telnet and > see the demos for self. I have been using Self in a text mode from home and can say it is very disapointing compared to the UI. Someone else ( sorry, I lost the message ) asked about running Self without the UI. It is easy - make sure the DISPLAY environment variable is not set up to a valid X server and call Self. It complains and asks if you want to abort, retry or continue without graphics. Choose the third option and there you are! > I there an existing port of self for linux. If not I would > be glad to contribute to the effort. Porting to Linux would be hard, but very worthwhile. You would have to rewrite the compiler to generate 386 code, but other than the register allocation I saw nothing there that is too Sparc dependent. I am writting a small Self interpreter that will run initially on Linux, but it will be very slow and not totally compatible with normal Self. I doubt you will be able to run large programs ( like Mango or Cecil ) on it. It will also use svgalib rather than X windows. The second version will run on the bare 386 hardware, so I don't expect the Linux version to ever become very usable. I'll post it here so anyone who is brave enough will be able to try it out. Regards -- Jecel

1 0

Re: Self demos
by Tilak Ravi 07 Apr '95

07 Apr '95

Yes! that is great having a m/c where we could telnet and see the demos for self. I there an existing port of self for linux. If not I would be glad to contribute to the effort. -tilak On Wed, 5 Apr 1995, Jecel Mattos de Assumpcao Jr. wrote: > On Tue, 4 Apr 1995 15:31:48 +0800, Randall.Smith(a)Eng.Sun.COM (Randy Smith) wrote: > > > [ suggestion to let people try Self over the net deleted ] > > > > Actually, we are thinking of establishing a machine outside pf Sun's > > firewall. Because you could share screens, and travel around on the > > infinite Self plain, Self would instantly be a "graphical MUD." Or "MOO," in > > fact. It would be interesting to see the performace of X over the raw > > internet. I hear it is terrible, but I have not personally observed > > it. > > Great idea! That way novices can meet with experts and have them help > go over any bumps! > > When I got Self 4.0alpha installed, it was in the middle of the > holidays and I wouldn't be able to go to the university for several > days. So I simply called term and txconn and tried it out over a > noisy 1200 bps line! It would take about 8 minutes to update the > screen after each click on the radar view's buttons. I would > have been *much* better at 9600. > > Within the US, I imagine most people have much faster connections. > > -- Jecel > >

1 0

Re: Self demos
by Jecel Mattos de Assumpcao Jr. 06 Apr '95

06 Apr '95

On Tue, 4 Apr 1995 15:31:48 +0800, Randall.Smith(a)Eng.Sun.COM (Randy Smith) wrote: > > [ suggestion to let people try Self over the net deleted ] > > Actually, we are thinking of establishing a machine outside pf Sun's > firewall. Because you could share screens, and travel around on the > infinite Self plain, Self would instantly be a "graphical MUD." Or "MOO," in > fact. It would be interesting to see the performace of X over the raw > internet. I hear it is terrible, but I have not personally observed > it. Great idea! That way novices can meet with experts and have them help go over any bumps! When I got Self 4.0alpha installed, it was in the middle of the holidays and I wouldn't be able to go to the university for several days. So I simply called term and txconn and tried it out over a noisy 1200 bps line! It would take about 8 minutes to update the screen after each click on the radar view's buttons. I would have been *much* better at 9600. Within the US, I imagine most people have much faster connections. -- Jecel

1 0

Re: Self demos
by sehyo＠netcom.com 05 Apr '95

05 Apr '95

>One of the problems with Self is that few people can see it running >as the machines needed to run it are not that common. > >If somebody could set up a computer that people on the internet could >telnet to ( if they have a fast enough connection ) and run the Self >tutorial, it might make a lot more people interested in the language. >The needed protection might be a problem ( you can do a lot of damage >from inside Self ) but could be worked out. I would also disable >saving Snapshots so that one user couldn't mess things up for the >next one. > >Of course, running X over the net can give people a bad impression >of a program. Even so, I think Self is something that has to be >seen to be believed! > >Just an idea... >-- Jecel > > What it would take make SELF independent of Sun/Solaris and X-window? Maybe some kind of portable UI interface? Or at least build SELF version with no UI dependency(like GNU Smalltalk) such that we can port to other platform? This would begin to popularize SELF. Or maybe GNU-SELF? -- sehyo chang --------------- Sehyo Chang Virtual Enterprise Technology, Inc. sehyo(a)netcom.com vox: 808.943.6215 fax: 800.203.3051 voice pager: 800.759.5622 (for quicker reply) 909 Kaheka St. Suite B404 Honolulu, HI 96814

1 0

Self demos
by Jecel Mattos de Assumpcao Jr. 04 Apr '95

04 Apr '95

One of the problems with Self is that few people can see it running as the machines needed to run it are not that common. If somebody could set up a computer that people on the internet could telnet to ( if they have a fast enough connection ) and run the Self tutorial, it might make a lot more people interested in the language. The needed protection might be a problem ( you can do a lot of damage from inside Self ) but could be worked out. I would also disable saving Snapshots so that one user couldn't mess things up for the next one. Of course, running X over the net can give people a bad impression of a program. Even so, I think Self is something that has to be seen to be believed! Just an idea... -- Jecel

1 0

Re: Self demos
by Randall.Smith＠Eng.Sun.COM 04 Apr '95

04 Apr '95

> > One of the problems with Self is that few people can see it running > as the machines needed to run it are not that common. > > If somebody could set up a computer that people on the internet could > telnet to ( if they have a fast enough connection ) and run the Self > tutorial, it might make a lot more people interested in the language. > The needed protection might be a problem ( you can do a lot of damage > from inside Self ) but could be worked out. I would also disable > saving Snapshots so that one user couldn't mess things up for the > next one. > > Of course, running X over the net can give people a bad impression > of a program. Even so, I think Self is something that has to be > seen to be believed! > > Just an idea... > -- Jecel > Actually, we are thinking of establishing a machine outside pf Sun's firewall. Because you could share screens, and travel around on the infinite Self plain, Self would instantly be a "graphical MUD." Or "MOO," in fact. It would be interesting to see the performace of X over the raw internet. I hear it is terrible, but I have not personally observed it.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest April 1995