World: r3wp
[!REBOL3 Extensions] REBOL 3 Extensions discussions
older newer | first last |
Robert 14-Mar-2011 [2465] | Why does it work with INTEGER than? |
Kaj 14-Mar-2011 [2466x2] | There you have created a memory clash between threads |
Immediate values are copied. That's the first thing to do to reduce thread synchronisation problems | |
Robert 14-Mar-2011 [2468] | Where is a memory clash? |
Kaj 14-Mar-2011 [2469x2] | Shared memory between threads. Elementary |
It may not clash in your case, but it certainly does nothing to fix the original problem | |
Robert 14-Mar-2011 [2471x2] | But the memory in one process between threads is shared by default. Or not? |
And as said, I now moved all callback structur related code to a single thread (not the one the interpreter runs in) and it crashes too. | |
Kaj 14-Mar-2011 [2473] | Yes, that's why thread programming can be very dangerous. The way to solve it is to use thread-local memory, or to handle global memory as if it were local |
Robert 14-Mar-2011 [2474x2] | Everything is on the heap, and I even added mutex around the callback code section without any luck. |
I can ensure that it's not a thread synchonisation problem. The memory for the callback is never used by anything on the c-side after setup. | |
Kaj 14-Mar-2011 [2476] | It's probably a thread synchronisation problem within R3 |
Andreas 14-Mar-2011 [2477] | can you temporarily disable threading in the library to see if that helps? |
Robert 14-Mar-2011 [2478] | No, but the same callback code works from an other place where it's the same thread as R3. |
Andreas 14-Mar-2011 [2479x4] | well, then that's looks pretty much like the problem |
the immediate solution is to have a piece of code, running in the same thread as the R3 host, which is used to initiate all callbacks | |
everwhere else, instead of initiating callbacks directly, you hand over control to this thread running this piece of code initiating the callback for you. that'll require basic inter-thread communication, is kaj already mentioned above | |
the real solution is to have R3 do this kind of thread synchronisation internally | |
Robert 14-Mar-2011 [2483x4] | Well, to get this code started I need to call it from R3, but than I can't return to R3 otherwise I get a new thread dealing with it. So this is not possible. |
The other option is to poll from R3 in regular intervalls. But as we miss timers at the moment, this won't work too. | |
But I could trigger a poll via callback sending an integer! :-) It's two rounds than but that would work. | |
Because the interger callback works. | |
Andreas 14-Mar-2011 [2487] | i assume you currently have roughly the following flow: - R3 calls into extension (via RX_Call) - extension calls into library, passing an extension-internal "activity" handler along - the library calls the extension's activity handler - the extension activity handler initiates a callback into R3 |
Robert 14-Mar-2011 [2488x2] | - R3 call init-lib - init-lib installs a listener, setups a C-level callback handler (CBH) and returns - the listener is sometimes triggered, calls the CBH (new thread) - CBH prepares Rebol callback, calls Rebol callback (and here it crashes with string!, not with integer!), continues and ends |
Ok, the callback / pull combo works :-) Not nice, but workaround. | |
Andreas 14-Mar-2011 [2490] | good to know :) |
Robert 14-Mar-2011 [2491] | To complete the sequence from above: - Rebol exectues the rebol side callback function, which make a synchronous call to the lib, getting all buffered messages and continues to process them |
Robert 25-Mar-2011 [2492x8] | I have a very strange effect: The init_block gets a c filename attached. The .r file that is used to generate the .h header file of course doesn't inlcude it. And the generated init_block numbers don't include it too. |
So, this happens at compile / run-time. | |
When entering RX_Init the init_block string allready has the c filename appended. | |
How can this be? I mean it's a const-char array. | |
Ok, so I found out that the last number wasn't 0. When generating the header file I get this as last line: 116, 105, 97, 108, 105, 122, 101, 100, 34, 10, }; This is the line makeing problems. When I change it to: 116, 105, 97, 108, 105, 122, 101, 100, 34, 10, 0 }; it works. | |
Seems the R3 script I use has a bug, there is a strange line: to-cstr: either system/version/4 = 3 [ ; Windows format: func [str /local out] [ out: make string! 4 * (length? str) out: insert out tab forall str [ out: insert out reduce [to-integer first str ", "] if zero? ((index? str) // 10) [out: insert out "^/^-"] ] ;remove/part out either (pick out -1) = #" " [-2][-4] head out ] ][ | |
The one commented. Than it works. | |
Is there an offical place to get the latest verison of this header converter script? | |
Kaj 25-Mar-2011 [2500] | The host kit is the only place I know of |
Oldes 25-Mar-2011 [2501] | Can someone explain me, why is Carl using such an 'encryption' and why not just to use it as const char like I do here: https://github.com/Oldes/R3-extension-FMOD/blob/master/main.c#L417 Is it because he wants to be compatible with some old compilers? |
Andreas 25-Mar-2011 [2502] | Oldes, yes, it's about compiler compatibility. |
Oldes 25-Mar-2011 [2503x2] | And compilers are affected? |
btw it's really strange.. I would thought that that's a basic thing. To be able easily define a string. | |
Andreas 25-Mar-2011 [2505x10] | Some compilers might be. |
Usually, MSVC is the problem, in such cases. | |
C90 requires compilers to support _single_ string literals (i.e. one quote "...") of at least 509 characters. | |
(C90 ~= C89 ~= "ANSI C") | |
C99 raides that minimum to 4095 characters. | |
And MSVC doesn't support C99. | |
Then there's also a limit how big concatenated strings can get (i.e. "..." "..." "..."). Which is 65k in MSVC, IIRC. | |
So, if you don't do extremely long lines and a 65k+ init string, you should be fine with string literals even in MSVC. | |
Which is why I don't care either :) String literals ftw! | |
Btw, here's my variation of a header generator script: https://github.com/earl/r3-zmq/blob/master/make-ext-header.r3 It has the nice advantage that it automatically generates a dispatch table for your commands, enabling a clean and concise RX_Call like: https://github.com/earl/r3-zmq/blob/master/zmqext.c#L31-35 | |
older newer | first last |