[Mono-devel-list] Embeding MONO and (p)threads

Francisco Puentes fran at cic-online.net
Tue Aug 12 19:05:36 EDT 2003


Is it possible to make a function in mono to include a pre build thread
in the GC threads list?
 
I suppose "mono_thread_attach(MonoDomain*)" do this, but it hangs when
it is called from a thread :-(
 
Something like "mono_thread_attach_prebuild(MonoDomain*, pthread_t)".
 
AND
 
Is it necessary call the function "mono_runtime_xxx_code()" to init
assembly 
                                                ^^^
                               I don't remember the real name yet ;-)
 
from a thread? It seems like a trick, but it is not a good trick in long
time.
 
The perfect execution for an embedded MONO is init it and run the
assembly from a unique thread (or several) and support that the extern
thread can control all the execution of the code.
 
For example: My project creates a lot of execution environments (with
fork), and each one of this can create a lot of threads, each one with a
different MONO domain. When an IP packet arrives it is sending to the
correct code (MONO code) and performs process over this one (perhaps
generating more IP packets). To allow more than one code type, each
thread (can) load a library which contains the execution control so I
can have a .so for dotNet, other for Java, etc... So pre compile the
code with GC is a lack.
 
It is an exigent environment to test mono in a complex surrounding. And
MONO seems like it isn't able to support that requirements.
 
I think that is most useful to have got a garbage collector simpler
(although slower) but more independent to allow a powerful MONO. And in
long term support a more complex (and efficient) garbage collector. I
think so because MONO is limited to be embedded in very simple
applications which have got the control inside the portable code and
*not* inside the native code (which is a powerful tool to powerful
applications). 
 
Well, they are some ideas ;-)
 
Can anybody send me an example of MONO embed into threads? Something
more complex than the example in CVS:/mono/samples/embed
 
Thanks in advance: Fran
 
-----Mensaje original-----
De: mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com] En nombre de Dick Porter
Enviado el: martes, 12 de agosto de 2003 11:55
Para: mono-devel-list at lists.ximian.com
Asunto: Re: [Mono-devel-list] Embeding MONO and (p)threads
 
On Tue, 2003-08-12 at 04:25, David Jeske wrote:
> On Mon, Aug 11, 2003 at 04:38:53PM +0100, Dick Porter wrote:
> > You need to make sure your whole embedded application is using the 
> > libgc-wrapped pthreads calls, not just the mono part.  See 
> >  <http://bugzilla.ximian.com/show_bug.cgi?id=46137>
http://bugzilla.ximian.com/show_bug.cgi?id=46137
 for more details. 
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> > 
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> > While this seems
acceptable for now, in the long term this seems like 
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> > a problem. As
someone else pointed out, this will prevent Mono from 
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> > being embeddable
inside any pre-built applications.
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> > 
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> > Can someone
elaborate more about what causes this problem, and what we 
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> > might do about it
in the future? For example:
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137>  
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> Its a libgc
requisite.
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137>  
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> > 
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> > Why does libgc
need to override pthread functions?
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137>  
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> It needs to be able
to stop all the threads when it does a collection, and therefore it
needs to know about all threads.  Theres some documentation about why
its done by cpp tricks rather than dynamic linker tricks, but I can't
remember the details offhand.
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137>  
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> > 
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> > What is the
problem with having some code talk directly to pthreads, 
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> > and some code talk
to libgc's pthread overrides?
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137>  
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> Segmentation faults.
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137>  
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> - Dick
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137>  
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137>
_______________________________________________
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137> Mono-devel-list
mailing list
 <http://bugzilla.ximian.com/show_bug.cgi?id=46137>
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
 <http://lists.ximian.com/mailman/listinfo/mono-devel-list>  
 <http://lists.ximian.com/mailman/listinfo/mono-devel-list>  
 <http://lists.ximian.com/mailman/listinfo/mono-devel-list>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20030813/73fd6f58/attachment.html 


More information about the Mono-devel-list mailing list