Hi David,
David Chisnall wrote:
I haven't seen enough of the code to be sure, but two things to be aware of:
1) There is a difference between clang and gcc in the implementations of
messages that return NSRect sent to nil. GCC will return an undefined rect,
clang will return a 0 rect.
Do you mean calling a method that returns on a rect on an object
instance which is nil? It shouldn't happen here, but I will check better.
Furthermore from what you write I'd expect gcc code going havoc (=
undefined rect) and not clang code.
2) It is*not* safe to pass an NSInvocation constructed with
-forwardInvocation: that returns an NSRect between threads. Doing so will
corrupt the stack in the caller context. It may work due to timing sometimes,
but it should never be relied upon. The argframe contains a pointer to the
caller's stack where the result will be written.
I don't know the whole code here either, but I don't think I am calling
between threads here. True that operations have a worker thread, but I
should not be calling it.
I noticed however that even on gcc where the code appears to work, when
I simulate several concurrent operations (I slow them down with a
sleep(1) and then "pause" them) clicking on the pause/continue buttons
doesn't appear to work reliably.
The whole code is set up to handle concurrent operations, but since this
array-out-of-bounds exception happened in the creation of another
operation, it can't have been tested since ages (I don't want to say
never...) since instantiation of any other operation failed. Add to this
that you could not reliably pause an operation either (bug fixed last
months) it was essentially impossible to have more than one operation
and this stress this code at all.
Riccardo
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
