Re: [DotGNU]Jabber.NET

[Rhys Weatherley]

On Sunday 16 February 2003 09:22 am, Simon Guindon wrote:

> The other major issue, which is the largest thing lingering over Jabber.NET
> compatibility is Threading, I know Rhys is busy with a great many things
> (including work) and from his statements theres no clear solution yet.
> Maybe we can try and brainstorm a little on this topic and see what arises?

That would be useful.

> So maybe I will throw out the first crazy idea.  I'm not that familiar with
> low level stuff like that, so bare with me.  I know from my Jabber
> experience, jabberd uses pthreads for threading, is some sort of pthreads
> wrapper that PInvoke's pthreads a possibility?

That wouldn't be a terribly good idea.  The runtime engine needs to know about 
the threads so that it can create the evaluation stacks and other structures.

The basic low-level stuff is mostly there in "pnet/support" already, but it 
needs to be joined up to "lib_thread.c".  And then we need to find everywhere 
that might need synchronization and add a lock.  The metadata lock is the 
most important, and there are already some macros for that in "engine.h".

There are two kinds of mutexes in "il_thread.h" and it is important to 
understand the difference.  "ILMutexCreate" creates a mutex that can be used 
in the runtime engine to synchronize its own structures.  "ILWaitMutexCreate" 
creates a mutex that can be used by a C# application to do synchronization.  

The difference is thread suspension.  A thread that holds the former type of 
mutex cannot be suspended while the mutex is held.  The latter type of mutex 
can be suspended.  This is to avoid race condition deadlocks in the engine.  
Consider this: thread A acquires the metadata lock and is then suspended;  
thread B tries to acquire the metadata lock and blocks; if nothing ever wakes 
up thread A, then the system deadlocks.

Because of this, if you are protecting a runtime engine data structure, you 
must use "ILMutexCreate".  But if you are implementing an internalcall in 
"lib_thread.c", you must use something like "ILWaitMutexCreate".  It is OK 
for C# application-level threads to deadlock due to poor program design, but 
not for the runtime engine.

If you want to help out, then start with the "Thread_*" functions in 
"lib_thread.c".  They should be relatively straight-forward wrappers around 
the functions in "il_thread.h".  I will hopefully have some time to implement 
the monitor cache this week and will tackle the "Monitor_*" internalcalls.

Someone (maybe Simon) mentioned that they didn't get a threaded engine when 
they built pnet.  This is normally because "configure.in" didn't detect it.  
If "configure.in" doesn't recognise the platform, then it is necessary to add 
an explicit "--enable-threads=pthreads" or "--enable-threads=win32" to the 
configure command-line.

Threading is not normally enabled by default because of libgc: if libgc 
doesn't support the system's thread package, then all bets are off.  Feel 
free to test on various platforms and add your platform to "configure.in" if 
it works (around line 117).

Cheers,

Rhys.