World: r3wp

GetCurrentThreadId: http://msdn.microsoft.com/en-us/library/ms683183(v=vs.85).aspx

Thanks going to add an output for this.

Ok, so as expected I get two different thread IDs. The callback is 
triggered from a different thread ID than the R3 host interpreter 
is running from.

Is there a simple way to call a function in the context of an other 
thread from the same process?

Does anyone know what the problem is, when the callback happens from 
different threads? Is it memory access?

There are many precautions that need to be taken to make a system 
thread safe, including memory access. Apparently, R3 isn't

Most probable is that the interpreter stack gets mixed up

Thread synchronisation is also a complex topic. You can't just execute 
a piece of code in the context of another thread. The other thread 
has to execute it, and to make it do so you need a framework for 
that, such as a messaging infrastructure

The R3 events system that is used in async callbacks is such an infrastructure, 
so the key to the solution should be there somewhere

Well, this gives me an idea... I create the CBI structs in thread 
A and use them from B... that sounds like a good candidate to fix.

Doesn't help.

Why does it work with INTEGER than?

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

Where is a memory clash?

Shared memory between threads. Elementary

It may not clash in your case, but it certainly does nothing to fix 
the original problem

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.

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

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.

It's probably a thread synchronisation problem within R3

can you temporarily disable threading in the library to see if that 
helps?

No, but the same callback code works from an other place where it's 
the same thread as R3.

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

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.

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

- 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.

good to know :)

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

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?

The host kit is the only place I know of

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?

Oldes, yes, it's about compiler compatibility.

And compilers are affected?