[M3devel] Fork bug

[Dragiša Durić]

IIRC, there is at least one recursive locking case in cm3 source, implemented ad-hoc in RTAllocator or RTCollector. Can’t remember right now.

Legitimate needs for recursive locking do exist. In special enough cases. It is not reason to make all MUTEX objects into recursive MUTEXes.

Daniel’s argument is a bit tangential here. New operator and specialized subclass are not comparable in any way.

On 11 Jul 2014, at 06:36, Hendrik Boom <hendrik at topoi.pooq.com> wrote:

> On Thu, Jul 10, 2014 at 10:39:41PM +0000, Daniel Alejandro Benavides Diaz wrote:
>> Hi all:
>> We can see this kind of reasoning in the The C++ Programming Language report quote in SPWM3, as it reads like "C++ has a lot of operators and while be explained where and if needed".
>> 
>> This is not reasonable for my, please don't make me attempt return Dragisha :)
>> 
>> Thanks in advance
>> 
>> De: Dragiša Durić [mailto:dragisha at m3w.org]
>> Enviado el: Miércoles, 09 de Julio de 2014 12:05 a.m.
>> Para: rodney.m.bates at acm.org
>> CC: m3devel
>> Asunto: Re: [M3devel] Fwd: Fork bug
>> 
>> We can implement specific MUTEX subclass with this behavior and use it where its use can be rationalised and where it is needed/correct-thing-to-do.
>> 
>> This way you get specific behavior without (in eyes of most people) breaking up with what has become normal and expected behavior of MUTEXes.
>> 
>> On 08 Jul 2014, at 21:20, Rodney M. Bates <rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>> wrote:
>> 
>> 
>> 
>> While we are working on MUTEX, I would like to propose making them
>> what I believe is meant by a recursive mutex, that is, one thread
>> can lock multiple times, the mutex being released only when the number
>> of unlocks catches up with the number of locks.
>> 
> 
> Recursive reentry into a semaphore might just possibly indicate a 
> serious bug in the logic of one's program.  It is not the purpose of 
> Modula 3 to paper over the effects of bad programming, however 
> convenient it seems to be.
> 
> Perhaps if you came up with useful, convenient, and elegant proof rules 
> for your desired behaviour, you might convince me otherwise.
> 
> -- hendrik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140711/eb43e456/attachment-0002.sig>