World: r3wp

I only have the source, where is the doc?

http://rebol.esperconsultancy.nl

I have a problem with a callback providing a string.

// call R3 callback
	RXA_COUNT(cbi) 		= 1;

/*
	RXA_TYPE(cbi, 1) 	= RXT_INTEGER;
	RXA_INT64(cbi, 1) = 123;
*/

	RXA_TYPE(cbi, 1) = RXT_STRING;
	RXA_SERIES(cbi,1) = RL_Make_String(message);;
	RXA_INDEX(cbi,1) = 0;

	int cb_error = RL_CALLBACK(cbi);

The RXT_INTEGER part works. But when using a RXT_STRING, R3 crashes.

Any idea what this could be? cbi = RXICBI structure.

The callback from the C side comes our from a multithreaded DLL. 
Maybe this is a problem.

Is hostkit A111 released or there are no changes compare to A110?

Our A111 version is released.

Is it possible for the callback to be executed simultaneously by 
multiple threads? Then your allocated REBOL string can be recycled 
if it has not reached the status of a reference in REBOL yet

It's also possible that the interpreter can't deal with multiple 
threads at all yet, but only Carl knows

I don't expect multiple threads call the function. But will cross-check. 
I could lock the string in the GC. Keeping the last reference from 
the C side.

The callback just prints the string.

I even used  RL_Protect_GC for the string going to the callback... 
no difference.

The DLL is used from two Rebol processes. One client and one server 
running from the same dir. I assume that the DLL doesn't share any 
memory between the processes. At least that's what I always understood 
how it works under windows.

I added a mutex around the callback and the string! creation. No 
effect, still crashes.

Those are the suggestions I would have, so I don't know what else 
to do

There are currently memory corruption bugs in R3, so it could be 
unrelated to threading

A shared library in two processes only shares the static code sections. 
The data sections are created for each process, so they can be considered 
independent. The only issue is multithreading within one process

You could try to have the progress callback in the cURL binding pass 
a series. cURL is singlethreaded, so this would establish whether 
it's a threading problem or an R3 memory management/callback problem

As said I can use a string from an other "not threaded" area in the 
code.

The problem is that I can't investigate further without Carl taking 
a look at it.

Sounds like callbacks not being threadsafe, then. Have you tried 
async callbacks?

I'm using the ASYNC mode. But changed tested both. Same effect.

Can you try ensuring that the callback is initiated from the same 
thread the R3 host (interpreter) is running in?

I will have to look at it. I assume it's not the case at the moment.


Anyone know how to find out the thread ID (not process ID) on Windows?

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?