In message 39789AA4.9BCF7727@chello.se you wrote:
I'm making some morphic stuff and use mouseEnter/mouseLeave events. But the morphs seem to miss about one out of five of the events.:-(
Is this something Tim's event VM/image stuff will fix or is my machine to slow or whats the deal?
I hope so, or it was all in vain! My stuff queues mouse stuff as well as keyboard stuff ( and once we have got it well worked out and in use there is no reason not to handle some of the other events of interest as well) so that you should not miss button presses.
By the way, I'v used the events change set from Tim for a day and can't notice any bad behavior yet. (I on a mac)
Good - you shouldn't notice anything at all without an updated VM and very little with one, until various explicitly-polling code is updated. Then you should only notice that mouse button presses are not missing anymore.
Is the event stuff comming to the mac VM ?
I hope to get to spoendan hour or so looking into it this weekend, byt if it takes longer than that I'll have to ask for a volunteer. So much to do, so little time...
tim
Tim,
Congratulations!
I have just installed your stuff and compiled a new VM: It works great!
For the others: Just click (in Morphic) in a Browser to InterpreterSupportCode>>macNetworkFile and immediately after this click on another window: It takes some time till the file string appears in the code pane and thereafter the other window comes to front!
This hasn't worked without events.
Thanks,
Stephan
Tim Rowledge wrote:
In message 39789AA4.9BCF7727@chello.se you wrote:
I'm making some morphic stuff and use mouseEnter/mouseLeave events. But the morphs seem to miss about one out of five of the events.:-(
Is this something Tim's event VM/image stuff will fix or is my machine to slow or whats the deal?
I hope so, or it was all in vain! My stuff queues mouse stuff as well as keyboard stuff ( and once we have got it well worked out and in use there is no reason not to handle some of the other events of interest as well) so that you should not miss button presses.
By the way, I'v used the events change set from Tim for a day and can't notice any bad behavior yet. (I on a mac)
Good - you shouldn't notice anything at all without an updated VM and very little with one, until various explicitly-polling code is updated. Then you should only notice that mouse button presses are not missing anymore.
Is the event stuff comming to the mac VM ?
I hope to get to spoendan hour or so looking into it this weekend, byt if it takes longer than that I'll have to ask for a volunteer. So much to do, so little time...
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Kept an open mind -- and his brains fell out.
In message 3978FAE1.5D9FD028@evolgo.de you wrote:
I have just installed your stuff and compiled a new VM: It works great!
I'm delighted to see confirmation of buildabiltiy by someone else. Thanks for trying it out so soon. Please do your best to spot problems - I'm sure there must be some relating to the faking-out of the old-style mouse status polling.
Ideas for other useful events to handle, critiques of the code etc all most welcome.
tim
Tim Rowledge wrote:
In message 3978FAE1.5D9FD028@evolgo.de you wrote:
I have just installed your stuff and compiled a new VM: It works great!
I'm delighted to see confirmation of buildabiltiy by someone else. Thanks for trying it out so soon. Please do your best to spot problems
- I'm sure there must be some relating to the faking-out of the
old-style mouse status polling.
Ideas for other useful events to handle, critiques of the code etc all most welcome.
Tim,
Do you think there is a way to make the sockets eventful, while still maintaining the backwards compatibility? It looks like the X events were buffered previously and there weren't any Semaphores being tapped. As you know, this isn't the situation with sockets. Perhaps we could include the flag information in the Socket event data, so that the Socket can tap his own semaphores, and then follow with the primitive call to read from the buffer.
Rob
tim
-- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim It's 10 o'clock. Do you know where your child processes are?
In message 3981527A.5488FAD2@home.com you wrote:
Do you think there is a way to make the sockets eventful, while still maintaining the backwards compatibility? It looks like the X events were buffered previously and there weren't any Semaphores being tapped. As you know, this isn't the situation with sockets.
I'm not entirely sure I follow you, but remember that the event stuff is currently _synchronous_ not asynchronous. So, no Semaphores are harmed by using the events. I did have one experimental system that used the old ST-80 idiom of a high priority Process that waited on a semaphore signalled by the VM, but that still required regular polling of the VM to get it to run ioProcessEvents() since there are no interrupts provided to do that asynchronously. I would also have to do some tedious asynchronous signalling code somewhere in the VM, unless maybe the externalSemaphore stuff is adequate for that already. Another big problem is that using the interrupt key (alt-. etc) will interrupt the event loop Process as often as not, and then you are truly screwed; can't run a UI dependent on events when the mechanism that delivers them is halted!
IF (big if) one could rely on asynchronous event notification from the OS, maybe through threads, signals, service calls, traps, boojums or whatever they call'em, then we could sensibly do interrupt driven events to the image. I just realised that a possible reason the interrupt-key problem exists in Squeak and didn't ever seem to in ST-80 is that ST-80 handled the interrupt-key in the event loop, not with a special separate Process/VM handler. Maybe changing that would help? Don't forget that not all OSs provide threads - certainly a lot of interesting ones for small and embedded systems don't (my main interests).
Trying to guess what you mean by making sockets event-driven (driving?), I can imagine making a completed socket (or indeed asynchfile, serial, whatever) call add an event to the event queue. I can't help thinking that it might be tricky to arrange getting the event to the right place though, whereas a semaphore being signalled is pretty much by definition the right place.
Have I answered any of your original question?
tim
Tim Rowledge wrote:
IF (big if) one could rely on asynchronous event notification from the OS, maybe through threads, signals, service calls, traps, boojums or whatever they call'em, then we could sensibly do interrupt driven events to the image. I just realised that a possible reason the interrupt-key problem exists in Squeak and didn't ever seem to in ST-80 is that ST-80 handled the interrupt-key in the event loop, not with a special separate Process/VM handler. Maybe changing that would help? Don't forget that not all OSs provide threads - certainly a lot of interesting ones for small and embedded systems don't (my main interests).
Does anyone know whether it's possible to signal an external Semaphore asynchronously? I looked at doing just this (including using SIGIO) for the Serial stuff, but didn't know how it would work.
Otherwise, you'd have to set a flag and then signal the Semaphore from the regular poll loop. Not a big gain for Serial and Socket communications under Unix, as you can already use select() to check readiness.
I was also going to generalize the polling (at least under Unix) to make it possible for any module that needs to be called for polling and/or needs to have file handles checked to do so.
Is this work still useful?
In message 3981D6C8.9639FE71@bike-nomad.com Ned Konz ned@bike-nomad.com wrote:
Does anyone know whether it's possible to signal an external Semaphore asynchronously? I looked at doing just this (including using SIGIO) for the Serial stuff, but didn't know how it would work.
You can use signalSemaphoreWithIndex asynchronously, but the semaphore wil only get _actually_ signalled the next time checkForInterrupts is called.
I was also going to generalize the polling (at least under Unix) to make it possible for any module that needs to be called for polling and/or needs to have file handles checked to do so.
Is this work still useful?
I think so - I'd love to see a simpler mechanism than the two ugly special cases currently in use. If you can think of a way to unify them, go for it.
tim
on 7/28/00 12:27 PM, Tim Rowledge at tim@sumeru.stanford.edu wrote:
In message 3981D6C8.9639FE71@bike-nomad.com Ned Konz ned@bike-nomad.com wrote:
Does anyone know whether it's possible to signal an external Semaphore asynchronously? I looked at doing just this (including using SIGIO) for the Serial stuff, but didn't know how it would work.
You can use signalSemaphoreWithIndex asynchronously, but the semaphore wil only get _actually_ signalled the next time checkForInterrupts is called.
Well... assuming signalSemaphoreWithIndex is perfectly interrupt safe is dangerous if you are driving it at a high interrupt rate from multiple OS threads. Right now it uses a non-atomic counter to track queued signals, if you hit things just right you could miss a signal. Also beware the table only holds 500 signals at time, so doing a burst of 1000 signals could be an issue.
In 2.8 I changed much of the code to fix some issues with how stuff gets deposited in the queue, versus how checkForInterrupts removes stuff from the queue, this solved most of the issues with lost signals, but to be *perfect* it would require the use of atomic operators to manage it's structure.
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== Custom Macintosh programming & various Smalltalk dialects PGP Key: DSS/Diff/46FC3BE6 Fingerprint=B22F 7D67 92B7 5D52 72D7 E94A EE69 2D21 46FC 3BE6 ===========================================================================
John M McIntosh wrote:
on 7/28/00 12:27 PM, Tim Rowledge at tim@sumeru.stanford.edu wrote:
In message 3981D6C8.9639FE71@bike-nomad.com Ned Konz ned@bike-nomad.com wrote:
Does anyone know whether it's possible to signal an external Semaphore asynchronously? I looked at doing just this (including using SIGIO) for the Serial stuff, but didn't know how it would work.
You can use signalSemaphoreWithIndex asynchronously, but the semaphore wil only get _actually_ signalled the next time checkForInterrupts is called.
Well... assuming signalSemaphoreWithIndex is perfectly interrupt safe is dangerous if you are driving it at a high interrupt rate from multiple OS threads. Right now it uses a non-atomic counter to track queued signals, if you hit things just right you could miss a signal. Also beware the table only holds 500 signals at time, so doing a burst of 1000 signals could be an issue.
In 2.8 I changed much of the code to fix some issues with how stuff gets deposited in the queue, versus how checkForInterrupts removes stuff from the queue, this solved most of the issues with lost signals, but to be *perfect* it would require the use of atomic operators to manage it's structure.
John,
What are atomic operators and why don't we currently have them in there? Are they not on all platforms? I've actually not seen this internal queue in the unix socket code as it relies on the os buffer for any particular handle.
cheers, Rob
--
John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== Custom Macintosh programming & various Smalltalk dialects PGP Key: DSS/Diff/46FC3BE6 Fingerprint=B22F 7D67 92B7 5D52 72D7 E94A EE69 2D21 46FC 3BE6 ===========================================================================
squeak-dev@lists.squeakfoundation.org
-
John M McIntosh -
Ned Konz -
Rob Withers -
Stephan Rudlof -
Tim Rowledge