https://bugs.freedesktop.org/show_bug.cgi?id=88092
Lionel Elie Mamane <lio...@mamane.lu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nopo...@novell.com,
| |uray.ja...@gmail.com
Version|4.3.5.2 release |3.5.4 release
Summary|Globals and Main are not |Globals are not available
|available as expected. |as expected
--- Comment #7 from Lionel Elie Mamane <lio...@mamane.lu> ---
I reproduce these behaviours with LibreOffice 3.5.4.2; I expect this is
actually "inherited from OOo".
We are dealing with several different (but interacting) issues here:
1) You (Bill) expect the Sub's execution to be strictly serialised
(that is, the one waits for the other to be completely finished before
starting) but that is not the case; their execution can be interleaved.
2) MessageBox seems not to react well to being run concurrently
(that is from two macros that run in parallel). The MessageBox
calls of one of the two macros are just silently skipped.
3) There is indeed a problem with structs "losing" their value
when the sub exits. That is, they act as local variables!
Point 1 means that there is a race condition between your initialisation in
main and using the value in PriorToReset. Also, since a MessageBox call
introduces a delay in the execution, the absence or presence of MessageBox
calls modifies the interdependent behaviour, as does any reordering of
statements or a busy delaying loop like "for i = 0 to 100000 / next i". Welcome
to concurrent programming...
Point 2 means that even though you think Main is not run, it actually is. Only
its MsgBox calls are "skipped over". You will find that if add a MsgBox right
at the beginning of Main, that MsgBox will run, and it is the MsgBox calls of
PriorToReset that will be skipped, while the other statements of PriorToReset
execute correctly. The same if you put a "wait 500" at the beginning of
PriorToRest. So actually in your "testingB", the first MsgBox of PriorToReset
allows (by the time you take to click it away) time for "Main" to continue
executing and initialise your globals, so by the time of the second MsgBox
call, they are indeed initialised.
Noel, Uray, does Basic (or some hidden corner of our API...) offer any
synchronisation / mutex / ... so that a Sub can wait for another Sub . I kinda
expected the basic interpreter to be single-threaded, so I was kind of
surprised that introducing a "busy wait loop" like:
for i=0 to 100000
next i
would make a difference, but I get a very clear result that introducing this
loop in sub Main allows execution of sub PriorToReset to start before Main is
finished (which seems to suggest that execution can be preempted and is not
purely cooperative multitasking, where instructions like MsgBox and Wait would
invoke Yield). OTOH, a busy wait in PriorToReset for a global that is set in
main (after the loop) to change value leads to an infinite loop.
Oh... I think I get it... It can be preempted by the start of a new macro from
an event (some code in LibreOffice calls the Basic interpreter), but is never
preempted on the initiative of the Basic interpreter. Is that it?
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
