|
Yumi Murakami
DoIt!AttachTheEarOfACat!
Join date: 27 Sep 2005
Posts: 6,860
|
01-11-2006 12:08
.. Yet another fun timing issue I've discovered.
I have an object which sends another one a bunch of link messages, then breaks the link. (For communication that can't be eavesdropped from outside.) The recieving object also checks that the object it's linked to is approved to send it data.
Resolving a bug I found that the last few link messages could arrive after the link was broken, so the security check failed with a warning that the object wasn't linked any more.
I knew since 1.7 we couldn't trust sequencing between objects, but can we really not trust it within one...
|
|
Ziggy Puff
Registered User
Join date: 15 Jul 2005
Posts: 1,143
|
01-11-2006 12:54
Maybe the link messages were 'sent' and 'arrived' before the link was broken, but arrival means they were sitting in the script's event queue. Maybe receiving script didn't get around to picking them up and processing them fast enough, and the link got broken while it was still processing the messages, so the remaining messages found the link gone.
|
|
Kenn Nilsson
AeonVox
Join date: 24 May 2005
Posts: 897
|
01-11-2006 17:59
I'd say Ziggy is 100% on. I've found that relying on the timing of link-messages is unreliable at best. Sure...the message itself is quick to execute, but the resulting processes may not be.
_____________________
--AeonVox--Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms chasing ghosts, eating magic pills, and listening to repetitive, addictive, electronic music.
|
|
Fenrir Reitveld
Crazy? Don't mind if I do
Join date: 20 Apr 2005
Posts: 459
|
01-11-2006 19:13
Yes, link messages are entirely dependant upon the event queue and how long a script holds on to it. If anything blocks a script, the events will pile up and suddenly you get a flood when processing resumes. (Or worse, you fill the queue up and things get silently dropped.)
You really can't rely upon link messages for timely processing. You will eventually get the message (assuming queue isn't overloaded of course), and they will be in order that they were sent, but they might be a bit stale.
|
|
Ben Bacon
Registered User
Join date: 14 Jul 2005
Posts: 809
|
01-12-2006 00:29
This is exactly the sort of issue we strike in all forms of multi-threaded programming - not just LSL. (In fact - LSL's non-rentrancy actually simplifies much of multi-threading).
My suggestion would be to have A send its messages to B, but not disconnect.
If B has no way of knowing when all messages are sent, A can end off with a "last message" indicator.
When B has everything, it unlinks A, if possible - else it sends an "acknowledge" to A which then unlinks.
This way, you are guaranteed of the sequence of operations being correct every time.
|