If i am reading this correctly, is the lack of support for unmanaged code in mono a case of three incomplete features namely:On 11/29/04 Francis Brosnan Blázquez wrote:
I'm trying to make the c# binding for some set of libraries which, in sort, makes petitions to a remote server without blocking the caller. In this context, the caller must suply a handler to manage the server response.
Later, when server response arrives, these libraries initiate a thread
and execute on it the Caller's handler.
The binding works fine until unmanaged code invoke the caller's handler inside the newly thread create.
I've made a litle test to show more presiselly what I'm trying to do. The follwing file is the unmanaged pice of code that has two ways to notify the caller throught its handler: 1) by creating a new thread, 2) by using the actual caller's thread.
[...]
When I execute this test I get the following:
---- $ ./Callback.exe Test init.. Recieved call on unmanaged side.. Calling back to managed side.. Recieved callback on managed side Values: 2 and some text Calling back finished.. Recieved call on unmanaged side.. Calling back to managed side..
** ERROR **: file mini.c: line 6558 (mono_get_lmf_addr): should not be reached
We could easily remove this assert and instead add the code to setup the thread to execute managed code. This won't solve the whole issue, though: the GC needs to know about the thread and its stack limits or it won't work correctly. There is also the issue of deciding which application domain should be set for the new thread. We should probably add a call to a function that does all this setup to the wrapper methods used to go from unmanaged to managed code.
lupus
1) Lack of Code access security stuff
2) Bits of monos internal setup
3) GC "pinning" and stack issues
If so is it that difficult to add this feature to mono (say once the work on code security is finished)
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
