[Mono-list] Requesting Assistance

[Jonathan Pryor]

While this would be better asked on mono-devel-list, there's little
reason it can't be answered here (except for noise, but there's lots of
noise already...)

Below...

On Wed, 2004-03-17 at 11:10, deepak pn wrote:
> Hi,
> 
>             I am a new bee in Contributing to the class library.
>
>             I have written test cases for about 8-10 classes and hence
> familiar with almost all classes in System.Threading namespace.
>
>             I am very much interested to complete *ALL* the TODOs in
> this namespace.  
>
>             I have a few problems:
>
>             1). The following code snippet appears in Thread.cs:
>                                         
>                 [MethodImplAttribute(MethodImplOptions.InternalCall)]
>                 private extern static Thread CurrentThread_internal();
>
>             I found from MSDN that the attribute methodImplAttribute
> is used here to specify that the method is defined else where and that
> the InternalCall refers to those methods implemented *WITHIN* the CLR.
> 
>             *WHERE* exactly are the definition of such methods found
> and *HOW* do I know all such methods.

Internal calls are written in C, and are in the "mono" CVS module.  In
particular, in mono/metadata/icall.c is huge-ass map, icall_map, which
maps a string to a function pointer.  "CurrentThread_internal" is mapped
to the C function mono_current_thread().

It's also possible to add new internal calls at runtime via
mono_add_internal_call().

>             2). I have implemented two TODOs.  I do not know whether
> they are fine.
> 
>                         a).  TODO1 :The false return value of Change()
> method of Timer.cs.
> 
>                         b). TODO2 : The Dispose( bool ).

Ask this on mono-devel-list.

>             3). What is the exact functionality of the WaitHandle()
> Constructor.

Ditto.  I would imagine that the constructor allocates the underlying
OS-native lock (semaphore, critical-section, etc.), storing this into
WaitHandle.os_handle.

> Can you please help me?

Maybe?  But mono-devel-list is a better bet...

And to answer a later question, yes, post these to bugzilla, IF THEY'RE
NEW.  Please make sure that they haven't already been reported, and if
these are already checked for in the unit tests, then I don't think they
need to be added to bugzilla, as "get the unit tests passing" is a
long-standing known issue.

<snip/>

 - Jon