World: r3wp

The index is part of the reference for series, not part of the series 
itself.

That's what I'm saying

Has anyone done some code using the RL_words_of_object, RL_Get_Field, 
RL_Set_Field for extensions? I would like to take a look at the code 
how to best use this stuff.


And, is it faster to seperate words & values on the C-side or to 
call an extension function just with two blocks: words, values?

Not in conjunction with RL_Words_Of_Object, but RL_MAP_WORD, e.g.:

type = RL_GET_FIELD(database, RL_MAP_WORD("connection"), &value);
...
value.addr = henv;

RL_SET_FIELD(database, RL_MAP_WORD("environment"), value, RXT_HANDLE);

Has anyone a simple callback example?

For callbacks to set the callback function, your C code must have 
a pointer to the object where it resides (an object you made or some 
other system context) and the name of the function, as a word id.

Those need to be set in the CBI structure:
cbi->obj = obj;
cbi->word = word;


The word ID can be retrieved with RL_MAP_WORD. And a self created 
context in the same way. But how do I rerieve the ID of the global 
context (do we still have such a thing?)?

You need to pass in a reference to the extension. There is no overarching 
global context, though there are a few centrally referenced contexts.

You need to pass in a reference to the extension. -> You need to 
pass to the extension a reference to the context containing the function.

Most words won't be "global" unless they are exported from a module 
(at which point they will be in the lib context) or system internal 
(sys context). User script words are in a task-local user context 
(once we get that working), and module words are in module-local 
contexts. I'd be shocked if most callback functions weren't at least 
module-local, or often in hidden inner contexts.

There's a callback example in the cURL binding, for progress info

In the documentation I'm simply using SELF, which would be the user 
context

There are no context IDs and there's no need for RL_MAP_WORD. RXA_WORD 
handles that

cbi->obj is of type REBSER* so this suggest to pass in a series. 
A string with the name of the context?


Brian, how does a  "reference to the context containing the function" 
look for this:

rebol []

myfunct: does []

What do I pass to the extension here?

cbi->word would be RXA_WORD of myfunct. But what is cbi->obj?

Just an object. Please refer to the cURL source and documentation

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