World: r3wp

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?

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