Squeak-dev July 2000

squeak-dev@lists.squeakfoundation.org

121 participants
566 discussions

Re: [Q][Unix][Sockets] Looking for explainations of 3 semaphores and error states.
by Lex Spoon 03 Aug '00

03 Aug '00

John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > >> You have thread (A) that reads data from a socket, and thread (B) that > >> writes data to the same socket. Thread (A) waits on read with Sempahore X > >> then thread (B) happens to wait on write on Semaphore X. > >> > > > > Two gripes about this scenario. First, why would you have a threading > > situation like this in practice? Second, why stop with a reader and a > > writer--suppose two threads are both writing data to the same socket > > (probably a UDP socket)? Or, what if one thread is watching for normal > > closes, and another is watching for errors? > > May I remind you the question is one or more semaphores? The example doesn't > have to elegant, just something to show one semaphore is insufficient. In > math or physics I only need one counter example to disprove a theory. I > think I've give an example to show one semaphore is a problem. Since the > objective is to have millions of people use Squeak I'm sure someone will > think my solution is elegant. > One counterexample would be enough, but it has to be one I agree with! I argued that your example isn't something we actually need to support, and I furthermore proposed a way to solve it anyway without using more semaphores. So to convince me, you need to either refute those two arguments or find another counterexample. Also, I had thought my UDP example was a straightforward extension of the problem and solution you've been describing. Isn't a major goal to support multithreaded access to a single socket? I wonder why one would stop at 3 threads, once they've decided that 1 isn't enough. Regarding performance, I have a standing question against whether the 3-semaphores interface would really better performance than simply tuning the image and VM. As far as I can reconstruct the reasoning, the idea is that you won't waste time trying to write when it's reading that has become available, and vice versa. Is that about right? Well, consider that trying to write and failing can be made an extremely fast operation. Futhermore, I'd guess that most applications tend to know which operation they are waiting for at any given time. In fact, many services will naturally refuse to read any new data until they have finished spooling out their response to the last query. For such applications, which I'd tentatively guess are the majority, it is possible to guess the appropriate operation every time. Theory aside, I eagerly await more performance data. Although, I hereby whine that people shouldn't performance tune before they have at least measured a problem! Anyway, it will be interesting to see. I betchya a 1-semaphore VM can saturate a 100MBit network, if a 3-semaphore VM can, but, we shall see. Overall, I still think the original VM interface was fine. Of course, even if everyone agreed, we'd faced with a cost analysis of switching the Mac port from 3 semaphores -> 1, versus switching all the other ports from 1->3. Note, though, around 10-20 man-hours have already been put into updating the Unix port, and it probably isn't finished yet. -Lex

2 1

Polymorphism and language
by Adam Bridge 02 Aug '00

02 Aug '00

I wonder if we're not asking the wrong question here. Language, it seems to me, is for expression. If we design a language (as opposed to allowing it to evolve) then we should have a goal for that language. What's the goal here? Although polymorphism is certainly an interesting capability shouldn't we be looking at the kinds of tasks we wish to perform? Would we demand an artist work in tempra when water color is what expresses the mood best? Personally I like the idea of small languages that do some things very very well. They are easy to learn because their concepts are clear. If languages can agree on ways to intermingle so I can write my image manipulation in one language and my text in another and my GUI in yet another -- and have them work together intimately and EASILY -- then I think we have a software system which is about expression first and language second. I'd love to easily, trivially, combine Smalltalk, Perl, Fortran, Obj-C and be able to easily explore other languages in this same context: it becomes easy to grow. Adam Bridge

2 1

Re: slimming the image
by Lex Spoon 01 Aug '00

01 Aug '00

A counter-example is Emacs. Emacs has *tons* of code available for it, and yet it all tends to work nicely together with any subset of the modules loaded. And Emacs doesn't even have namespaces! It's all done by hand. I don't know why it works out, but it certainly does, somehow or another. It's at least *possible*. -Lex Paul Fernhout <pdfernhout(a)kurtz-fernhout.com> wrote: > Dan Ingalls wrote: > >> [Mention of difficulties slimming image] > > People will tell you this is the problem with the unified image approach, > > but I disagree. The problem is simply that we haven't drawn appropriate > > lines between the various parts of the system, so when you cut one out, > > you're left with dangling dependences. > > The deeper issue is management of complexity. In a Smalltalk sense, it > is that a "module" providing a certain functionality typically consists > of multiple classes that need to cooperate to get things done (thus a > Smalltalk class really isn't a "module" in any meaningful sense). > > Of course this is made worse by the fact that subclassing or copying a > whole bunch of classes in Smalltalk is a lot of work, so it is easier to > patch new functionality directly into the old classes as a practical > matter, as was done with the C code generation stuff added to the parser > classes. > > One can manage complexity by hand in Smalltalk (being very careful about > how modules are created). You can do it in assembler or C by hand as > well. Modula or modern Lisps or even Delphi Pascal at least address this > issue somewhat by having modules or units providing some sort of defined > functionality and having defines interfaces. One can also do somethign > like this by using something like ENVY (with its application and the > extension concepts). > > But in practice it is very hard to do it in Smalltalk by hand when a lot > of developers are working together -- see my "SystemDictionary>>version" > post where I cite: > SystemDictionary>>version > "Answer the version of this release." > ^ EToySystem version , ' of ' , EToySystem versionDate > > The issues were put very eloquently by Les Tyrrell and others (esp. in > his > Re: Belling the cat of complexity (was: Ship it with Squeak) > Resent-Date: 30 Jun 2000 23:20:05 -0000) > As long as a monolithic big image is what people download and what is > supported as part of the mainline, testing for a shippable app is a > nightmare, because a pruned image is a new (untested) image and has to > be retested. Building up from a solid core is the only realistic path to > reliability. > > I feel strongly on this complexity management issue -- enough to start > wondering whether it would be better for my own efforts to pick another > cross-platform solution that has a stable core (MzScheme?) and add on > Squeak like functionality. I guess "SystemDictionary>>version" is making > me despair at realizing how deep the Squeak complexity problem has > grown. Squeak has lots of great ideas and great work, but it's the > "building your house on sand" concept. If you want your house to stand, > either move it onto rocks or put in deep piles underneath. Either is a > lot of work. It's easier to just add on to a house someone else already > built on a rock. > > I understand the value to SqueakC to have everyone banging on the big > image SqueakC uses its own work. But I think in the end you and many > other Squeakers would be better served by having a slim image as the > mainline system, with everything possible (including Morphic) being > loaded as needed. A convenience kitchen sink image is OK; just always > build it from the slim core for each release. > > (And ideally that core image should be built via the ANSI declarative > approach but that is another rant.) > > > I think that real value would come from declaring this as a project, > > with a goal of having maybe 20 discardX methods that really worked > > and that wouldn't get out of date in the next month. > > I just can't see this really being a good solution. It will get out of > date immediately in a new release and produce lots of difficult to > maintain code. This is because every remove method will have to be > written by an expert (or someone becoming one) on that subsystem (and > every other subsystem that uses it). > > -Paul Fernhout > Kurtz-Fernhout Software > ========================================================= > Developers of custom software and educational simulations > Creators of the Garden with Insight(TM) garden simulator > http://www.kurtz-fernhout.com

2 1

[SF][RFC] sqXWindow.c split into pieces - please comment
by David T. Lewis 01 Aug '00

01 Aug '00

Here is something I would like to take off the to-do list. I split the sqXWindow.c file (current version from SF) into three C files and a couple of new headers. If you are doing any work with sqXWindow.c, I would appreciate if you can take a quick look at this and let me know if it looks OK. If there are no objections, I will update SourceForge in a day or two. The files are: sqMain.c sqXWindow.c sqXWindow.h sqCopyImage.c sqCopyImage.h Dave p.s. Apologies to anyone who might be currently working on changes to sqXWindow.c. Having done this once, I can now redo this work if needed, although I would obviously like to avoid that if possible.

3 4

Re: [Q] Does anyone have a radix search trie Smalltalkimplementation?
by Rob Withers 01 Aug '00

01 Aug '00

Thank you Alan, I was starting to be a little concerned that no one was interested. :) Thanks for the huge pointer on where to go next. It definitly needs a speed up and better performance tests/monitors. We'll get better algorithms. What I am really interested in is the full unification in CLOS. It almost seems as if it is related to AOP. A single object may want to register for several events with different patterns. Since every object in the system can be considered a 1 arity tuple, we could get Object to understand match: and implement a doubleDispatch to locate special cases. You may want to register with an ad hoc match algorithm, however. VM and JIT support could go a long way on restricted class spaces. Since we have a oop fence with the vm event channel, we could possibly apply the idea of an 'Protocol class' which could help us find a restricted class implementation of the space structure and algorithms. Is this the path of least resistence? Could you tell us a little more about full unification in CLOS? cheers, Rob 8-) Alan Kay wrote: > > Rob -- > > Much work was done in the area of fast correlation of tuples with > event patterns for OPS5 at CMU and later, ART (automated reasoning > tool) at Inference Corp (spinoff from CMU, they used to be located in > LA). Most of this would work very well for Linda (whose pattern > matching is kind of a minimal subset of what ART could do). You > should find some great algorithms for this in the literature. ART, in > particular, was pretty fantastic at being able to have many thousands > of patterned watchers all looking at a big constantly changing tuple > space 1000s of times per second. Several really serious mainframe and > terminal systems (e.g. for American Express, a large airline, etc.) > were done in ART in the 1980s. > Much earlier (late 60s) Dave Fisher (CMU) and I independently > showed NLogN event expression catchers (like boolean expressions but > seeming to continuously and efficiently evaluate), some of whose > technology was later incorporated into the highly engineered OPS5 > (and then ART) stuff. > You could also look at how LINDA has been incorporated into CLOS > with full unification instead of just simple matching ... > I.e. a lot has been done in this area over the years. > > Cheers, > > Alan > > At 10:32 AM -0700 7/30/00, Rob Withers wrote: > >Or any abstract tree implementation. There's no sense in reinventing > >the wheel. Even better would be a Slang implementation. 8-) (drool) > > > >thanks, > >Rob > > > >-- > >-------------------------------------------------- > >Smalltalking by choice. Isn't it nice to have one! -- -------------------------------------------------- Smalltalking by choice. Isn't it nice to have one!

3 3

Re: [UNIX][ALPHA][NET] When to tap the r/w sems?
by Lex Spoon 01 Aug '00

01 Aug '00

Rob Withers <slosher2(a)home.com> wrote: > Lex Spoon wrote: > > > > It seems reasonable to me to tap when there is a *change* in the read or > > write flag. In fact, if the image sockets code is modified to drain > > semaphores instead of just reading one signal at a time, then we could > > completely stop checking whether we think the image is watching or not, > > and just signal any events that someone in the image might be interested > > in. > > Right on. In that scenario, I think we would only have one Semaphore in > the platform socket code to serialize the interaction of the socket > commands (create, listen, accept, connect, close, shutdown, read, write) > and the async handlers. If we link into Tims's event code and buffer in > the socket code (performance), then we could wait on an image semaphore > (for that socket), perhaps with a timeout, and upon a signal from the > arrival of an event, we would check socket state or read data. There > could also be a write buffer in the platform socket code, so it should > be thread safe. I didn't follow all this, but it sounds pretty cool. Certainly socket events could go through a global event stream. Also certainly, they don't have to, and things are okay as they are. Either way seems okay. > > I am not sure I am following you on the change in flags. In fact, if we > make the sockets eventful, then we would always send an event when > anything happens (connect, read, write, exception). select() tells you whether a socket is read-able or not, but it doesn't tell you when it *becomes* readable. So you have to watch for a transition from unreadable to readable. The image will only see events, but the VM authors have to actually manufacture those events. > > > In Unix, this would suggest that dataHandler and friends be given seven > > arguments: > > > > the fd > > the current read, write, and exceptions flags > > the previous read, write, and exceptions flags > > > > The data handlers can then signal the relevant semaphore whenever read > > or write goes from 0 to 1. > > > This approach *does* require some slight trickery in order to make the > > select() wait properly: do one select to wait for stuff to happen, and > > then do another select() to update all three flags for all open sockets. > > (Note you can't ask select() to watch for a flag changing from 1 to 0). > > I am confused about this. The tapFlags in the current code are to > inform the async handlers of intent. If the intent flags get set in the > sendDone or dataAvailable primitives, then the client is going to wait > on the semaphore, so tap on it. The scenario you painted with the read, > write, and excpetion flags sound like the FD flags for select. I am not > entirely sure about the select() call but isn't it known when the select > occurs that whatever the current flags are set, is the event that > occu Keeping track of whether someone is watching for read events seems a little complicated. Furthermore, it still sends events that get ignored: for example, I've written a good bit of network code that does call sendDone but which doesn't use waitForSendDone:. This code doesn't wait on the semaphore until it closes the socket down. So I propose, just signal every event, and if no one is interested, they can just ignore them. The image code should then be updated to deal with a slew of identical events arriving in a row. -Lex

2 1

Re: [Q] Also looking for a TimeSlicer class (Squeak)
by Lex Spoon 01 Aug '00

01 Aug '00

Please note that we really don't want *all* processes to get preempted. It is convenient most of the time that you don't get preempted by processes at the same priority, because it usually allows you to do without locks. Processes should have to register if they want to be shuffled by the shuffler. By the way, what priority should the processes get toggled to? Perhaps the register method should have a parameter for the desired lower priority. One final note: multiple schedulars running in the same image is bound to cause trouble, and yet, but is there any one schedular that will make everyone happy? Why do people want preemption at all, by the way? -Lex Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > The canonical example of this is simply a high priority loop waiting on > a Delay. Each time the Delay fires it will stir up the process list at > the priority of the suspended process (and by extension any other > priority level that might get involved) assuming of course that the > suspend is implemented to add the suspended process at the back of the > list. Not all systems actually do that - VW used to put it at the front > of thelist and so the same process would get resumed. Might still be > like that for all I know. > > I think there is all the VM support you need already there, what with > the Delay etc. Note that checkForInterrupts is already involved since it > is the mechanism by which the Delay termination is noticed! > > I imagine that it might be useful to add some VM support to directly > deal with a special timer for process stirring and thereby reduce by a > small amount the allocating and setting up of actual Delay objects, but > it would be a pretty minimal improvement I suspect. > tim > > -- > Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim > Never write software that anthropomorphizes the machine.

2 1

Re: [ENH] Alternative EventSensor
by Lex Spoon 01 Aug '00

01 Aug '00

Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > > I like the concept of time stamps. > So do I, unless it costs a lot - although keystroke and mouse button > events are usually relatively slow (ie maybe a couple of hundred aminute > at worst) some events (people have been considering serial or > socket events for example) might be much higher bandwidth and could > cause a problem if getting the time is costly. Something to keep an eye > on; some OSs provide timestamps on event, some don't. Some have > expensive clock() calls, some are cheap. We have to check and make sure > we don't make life good on one platform by ruining it on another, just > like always. > > Hmm, I just put these two ideas together. On Unix, the timestamps for X events are going to be based on a completely separate clock from the ones for sockets. I guess the VM can just stamp the times itself, and ignore whatever X says, but something is definately lost: the input events will be less precise! The alternatives on Unix seem to be: 1. Only use *input events*, and allow for precise timings. 2. Mix all events into the same queue, but use imprecise timings. -Lex

3 2

[BUG] Symbol>>hash
by Andres Valloud 01 Aug '00

01 Aug '00

Hi. Now, 'To: ' = #'To: ', but their hashes don't match. Removing Symbol>>hash and rehashing all sets seems to work, but... is that ok? Symbol>>hash involved a primitive, and I think that if the primitive was there, it was because speed was important. Or maybe it was a leftover? Andres.

2 1

Re: modelling program comments
by Karl Goiser 01 Aug '00

01 Aug '00

Yeah, moving the mouse over a variable, for example, could pop up its comments...

1 0

Jump to page: