Home / Browse / coThreads / Mail / Archive

coThreads

Email Archive: cothreads-discuss (read-only)

[cothreads-discuss] enhanced modules and the lack of naming idea

From: Zheng Li <zheng_li@us...> - 2007-09-22 09:23

Hi,

I'm refining the implementation of Event/process and Condition/process. I ran
into a situation where reader(shared)/writer(exclusive) lock is
wanted. Actually, similar mechanics is already used inside the implementation
of Stm/threads, now it seems that I should do something similar for
process. This led me to think: if it's so frequently used, rather than embedded
them as insider helper, how about provide them as enhanced modules? 

For example, the standard modules can extended in the following ways

  - Mutex: support reader/writer locks
  - Condition: support capacity 
  - Event: support future

What do you think? 

On the other hand, I really have problem in naming them. They are enhanced (but
not compatible) version of the original modules. For example, in the new Mutex
module, ''lock'' function will take a optional variable indicate how the mutex
should be locked (shared or exclusively), this is not compatible with original
''lock''. 

Naming them as "Comutex" "Cocondition" "Coevent" is a bit confusing, since they
are not in the same relation as "Cothread" with "Thread" (compatible super set)
and the "Co" won't stand for anything in these cases. Naming them as "MutexExt"
or "ExtMutex" sounds a bit cumbersome.

Any ideas?

-- 
Zheng Li
http://www.pps.jussieu.fr/~li

Thread View

Thread	Author	Date
[cothreads-discuss] enhanced modules and the lack of naming idea	Zheng Li <zheng_li@us...>

Re: [cothreads-discuss] enhanced modules and the lack of naming idea

From: Erik de Castro Lopo

Zheng Li wrote:

> 
> Naming them as "Comutex" "Cocondition" "Coevent" is a bit confusing, since they
> are not in the same relation as "Cothread" with "Thread" (compatible super set)
> and the "Co" won't stand for anything in these cases. Naming them as "MutexExt"
> or "ExtMutex" sounds a bit cumbersome.
> 
> Any ideas?

Since these are extensions to existing modules, could you do something like
ExtString and ExtList modules from ExtLib do to standard String and List
modules?

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"A program invented (sic) by a Finnish computer hacker and handed out
free in 1991 cost investors in Microsoft $11 billion (_6.75 billion)
this week." - Andrew Butcher in the UK's Sunday Times, Feb 20th, 1999

Re: [cothreads-discuss] enhanced modules and the lack of naming idea

From: Zheng Li <zheng_li@us...> - 2007-09-25 10:22

Erik de Castro Lopo <mle+ocaml@...> writes:
> Zheng Li wrote:
>
>> 
>> Naming them as "Comutex" "Cocondition" "Coevent" is a bit confusing, since they
>> are not in the same relation as "Cothread" with "Thread" (compatible super set)
>> and the "Co" won't stand for anything in these cases. Naming them as "MutexExt"
>> or "ExtMutex" sounds a bit cumbersome.
>> 
>> Any ideas?
>
> Since these are extensions to existing modules, could you do something like
> ExtString and ExtList modules from ExtLib do to standard String and List
> modules?

Not really. Two problems here:

 - IIRC, ExtList and ExtString are compatible superset of standard List and
   String, just like Cothread with Thread, this is crucial to the "open" trick
   they use (so that ExtList.List will fully cover List). But here we're
   talking about incompatible extensions.
 - Even if it's possible (like in the case of Cothread/Thread), I don't like
   ExtLib's "open trick", which is so implicit that it can confuse people (and
   oneself). That's why I didn't take the same approach to make Cothread module
   as Cothread.Thread.

Anyway, I made up my mind. Because the extended modules are different from the
standard ones in so many aspects (more than I though previously, esp. on the
Event/Future idea), I will give them new names. 

All the best.
-- 
Zheng Li
http://www.pps.jussieu.fr/~li