From hosking at cs.purdue.edu Thu Jul 3 21:28:30 2014 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 3 Jul 2014 15:28:30 -0400 Subject: [M3devel] Fwd: Fork bug References: Message-ID: I wonder if we should not move to a surrogate parent model to make this cleaner in general? Since fork is (or should be) only used in service of creating a new process (i.e., fork + exec) then this technique would save us a lot of grief. Thoughts? In the surrogate parent model, a program forks a child process at initialization time. The sole purpose of the child is to serve as a sort of "surrogate parent" for the original process should it ever need to fork another child. After initialization, the original parent can proceed to create its additional threads. When it wants to exec an image, it communicates this to its child (which has remained single-threaded). The child then performs the fork and exec on behalf of the original process. Begin forwarded message: > From: Peter McKinna > Subject: Fork bug > Date: July 2, 2014 at 10:30:24 PM EDT > To: Antony Hosking > > Hi Tony, > > That fork bug on posix doesn't appear to be fixed, so just to recap the problem. In the threadtest program if you have a bunch of threads creating mutexes and having them collected then get a thread that does a few forks what can happen is that the child executes atforkchild as I think the first thing it does which calls initwithstackbase which does an allocation and possible collection. Unfortunately the weaktable from the parent may be non empty and this is the only thread executing. It calls the cleanup of those mutexes of nonexistant threads some of which may be locked. If they are locked then pthread_mutex_destroy returns ebusy. Then the child exits with the abort in pthread_mutex_delete. > Whether the abort is needed I dont know. In this case the error can be safely ignored. One could try to see if the owner of the mutex is still alive and not abort in that case. Otherwise if one is sure the child is going to do an exec almost immediately then disabling the collector in atforkchild could work. > In the broader picture anything thats got a weak ref still active could cause problems if one thread does a fork. The weak callback could do anything. > Anyway I dont know what the fix is. > > Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 3 23:09:52 2014 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 3 Jul 2014 17:09:52 -0400 Subject: [M3devel] Fork bug In-Reply-To: References:

Message-ID: <9207B1F5-ADD9-4BAF-BC23-880E206DD2F6@cs.purdue.edu> Or, more directly, why do we not simply use vfork for Process.Create as we used to? It suspends the parent until the exec, which avoids all the nastiness, so long as we are careful in the child until the exec. As I recall though, cvsup relied on full-blown fork, which was how we ended up in this mess in the first place. So, that means a fix is still needed. I suspect we will need to revise the implementation of MUTEX to avoid having the pthread mutex held while the Modula-3 MUTEX is held. Instead, we?d need state in MUTEX to record the holder, plus a waiters field to record those waiting for the mutex. Then, we can guarantee that no pthread mutex will be locked at the time of the fork using the machinery we already have. On Jul 3, 2014, at 3:28 PM, Tony Hosking wrote: > I wonder if we should not move to a surrogate parent model to make this cleaner in general? > Since fork is (or should be) only used in service of creating a new process (i.e., fork + exec) then this technique would save us a lot of grief. > Thoughts? > > In the surrogate parent model, a program forks a child process at initialization time. The sole purpose of the child is to serve as a sort of "surrogate parent" for the original process should it ever need to fork another child. After initialization, the original parent can proceed to create its additional threads. When it wants to exec an image, it communicates this to its child (which has remained single-threaded). The child then performs the fork and exec on behalf of the original process. > > > Begin forwarded message: > >> From: Peter McKinna >> Subject: Fork bug >> Date: July 2, 2014 at 10:30:24 PM EDT >> To: Antony Hosking >> >> Hi Tony, >> >> That fork bug on posix doesn't appear to be fixed, so just to recap the problem. In the threadtest program if you have a bunch of threads creating mutexes and having them collected then get a thread that does a few forks what can happen is that the child executes atforkchild as I think the first thing it does which calls initwithstackbase which does an allocation and possible collection. Unfortunately the weaktable from the parent may be non empty and this is the only thread executing. It calls the cleanup of those mutexes of nonexistant threads some of which may be locked. If they are locked then pthread_mutex_destroy returns ebusy. Then the child exits with the abort in pthread_mutex_delete. >> Whether the abort is needed I dont know. In this case the error can be safely ignored. One could try to see if the owner of the mutex is still alive and not abort in that case. Otherwise if one is sure the child is going to do an exec almost immediately then disabling the collector in atforkchild could work. >> In the broader picture anything thats got a weak ref still active could cause problems if one thread does a fork. The weak callback could do anything. >> Anyway I dont know what the fix is. >> >> Peter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Jul 8 21:20:28 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 08 Jul 2014 14:20:28 -0500 Subject: [M3devel] Fwd: Re: Fwd: Fork bug In-Reply-To: <53BB4943.4000509@lcwb.coop> References: <53BB4943.4000509@lcwb.coop> Message-ID: <53BC447C.6060609@lcwb.coop> Resent after 24 hours: 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. I don't remember the details off the top of my head, but there is a place in Trestle where you have to acquire a MUTEX but it is very difficult or impossible to know whether different code on the same thread already has done so. The different code isn't under your control either. Some runtime scheme to figure it out dynamically would be tantamount to, but messier than, just having a recursive MUTEX. I recall there are other places as well where similar problems arise. It would greatly simplify things when needed. The only disadvantage I can think of is there might be a case where runtime detection of a second lock attempt by the same thread would help find a bug. Maybe the RTS could have a way of setting the behavior of a specific MUTEX. On 07/03/2014 02:28 PM, Tony Hosking wrote: > I wonder if we should not move to a surrogate parent model to make this cleaner in general? > Since fork is (or should be) only used in service of creating a new process (i.e., fork + exec) then this technique would save us a lot of grief. > Thoughts? > > In the surrogate parent model, a program forks a child process at initialization time. The sole purpose of the child is to serve as a sort of "surrogate parent" for the original process should it ever need to fork another child. After initialization, the original parent can proceed to create its additional threads. When it wants to /exec/ an image, it communicates this to its child (which has remained single-threaded). The child then performs the /fork/ and /exec/ on behalf of the original process. > > > > Begin forwarded message: > >> *From: *Peter McKinna > >> *Subject: **Fork bug* >> *Date: *July 2, 2014 at 10:30:24 PM EDT >> *To: *Antony Hosking > >> >> Hi Tony, >> >> That fork bug on posix doesn't appear to be fixed, so just to recap the problem. In the threadtest program if you have a bunch of threads creating mutexes and having them collected then get a thread that does a few forks what can happen is that the child executes atforkchild as I think the first thing it does which calls initwithstackbase which does an allocation and possible collection. Unfortunately the weaktable from the parent may be non empty and this is the only thread executing. It calls the cleanup of those mutexes of nonexistant threads some of which may be locked. If they are locked then pthread_mutex_destroy returns ebusy. Then the child exits with the abort in pthread_mutex_delete. >> Whether the abort is needed I dont know. In this case the error can be safely ignored. One could try to see if the owner of the mutex is still alive and not abort in that case. Otherwise if one is sure the child is going to do an exec almost immediately then disabling the collector in atforkchild could work. >> In the broader picture anything thats got a weak ref still active could cause problems if one thread does a fork. The weak callback could do anything. >> Anyway I dont know what the fix is. >> >> Peter > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Wed Jul 9 01:12:20 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 08 Jul 2014 18:12:20 -0500 Subject: [M3devel] Fwd: Re: Fwd: Fork bug In-Reply-To: <6A40CC9E-3EB4-40FF-BDC7-4300E3A10D4C@purdue.edu> References: <53BB4943.4000509@lcwb.coop> <53BC447C.6060609@lcwb.coop> <6A40CC9E-3EB4-40FF-BDC7-4300E3A10D4C@purdue.edu> Message-ID: <53BC7AD4.6070605@lcwb.coop> On 07/08/2014 03:27 PM, Antony Hosking wrote: > I would hesitate to do this mainly because the C and POSIX standards don?t define behavior for re-entrant locks. > > From http://en.cppreference.com/w/c/thread/mtx_lock: > > Defined in header || > > int mtx_lock( mtx_t * mutex ); > (since C11) > > > Blocks the current thread until the mutex pointed to by |mutex| is locked. > The behavior is undefined if the current thread has already locked the mutex and the mutex is not recursive. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So if we just label it recursive, this would not apply. From http://http://en.cppreference.com/w/cpp/thread/recursive_mutex: std::recursive_mutex C++ Thread support library std::recursive_mutex Defined in header class recursive_mutex; (since C++11) The recursive_mutex class is a synchronization primitive that can be used to protect shared data from being simultaneously accessed by multiple threads. recursive_mutex offers exclusive, recursive ownership semantics: A calling thread owns a recursive_mutex for a period of time that starts when it successfully calls either lock or try_lock. During this period, the thread may make additional calls to lock or try_lock. The period of ownership ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ends when the thread makes a matching number of calls to unlock. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ When a thread owns a recursive_mutex, all other threads will block (for calls to lock) or receive a false return value (for try_lock) if they attempt to claim ownership of the recursive_mutex. The maximum number of times that a recursive_mutex may be locked is unspecified, but after that number is reached, calls to lock will throw std::system_error and calls to try_lock will return false. The behavior of a program is undefined if a recursive_mutex is destroyed while still owned by some thread. The recursive_mutex class satisfies all requiremenets of Mutex and StandardLayoutType. Member types Member type Definition native_handle_type implementation-defined Member functions (constructor) constructs the mutex (public member function) (destructor) destroys the mutex (public member function) operator= [deleted] not copy-assignable (public member function) Locking lock locks the mutex, blocks if the mutex is not available (public member function) try_lock tries to lock the mutex, returns if the mutex is not available (public member function) unlock unlocks the mutex (public member function) Native handle native_handle returns the underlying implementation-defined thread handle (public member function) > > > On Jul 8, 2014, at 3:20 PM, Rodney M. Bates > wrote: > >> >> Resent after 24 hours: >> >> >> 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. >> >> I don't remember the details off the top of my head, but there is a >> place in Trestle where you have to acquire a MUTEX but it is very >> difficult or impossible to know whether different code on the same >> thread already has done so. The different code isn't under your >> control either. Some runtime scheme to figure it out dynamically >> would be tantamount to, but messier than, just having a recursive MUTEX. >> >> I recall there are other places as well where similar problems arise. >> It would greatly simplify things when needed. >> >> The only disadvantage I can think of is there might be a case where >> runtime detection of a second lock attempt by the same thread would >> help find a bug. Maybe the RTS could have a way of setting the >> behavior of a specific MUTEX. >> >> On 07/03/2014 02:28 PM, Tony Hosking wrote: >>> I wonder if we should not move to a surrogate parent model to make this cleaner in general? >>> Since fork is (or should be) only used in service of creating a new process (i.e., fork + exec) then this technique would save us a lot of grief. >>> Thoughts? >>> >>> In the surrogate parent model, a program forks a child process at initialization time. The sole purpose of the child is to serve as a sort of "surrogate parent" for the original process should it ever need to fork another child. After initialization, the original parent can proceed to create its additional threads. When it wants to /exec/ an image, it communicates this to its child (which has remained single-threaded). The child then performs the /fork/ and /exec/ on behalf of the original process. >>> >>> >>> >>> Begin forwarded message: >>> >>>> *From: *Peter McKinna > >>>> *Subject: **Fork bug* >>>> *Date: *July 2, 2014 at 10:30:24 PM EDT >>>> *To: *Antony Hosking > >>>> >>>> Hi Tony, >>>> >>>> That fork bug on posix doesn't appear to be fixed, so just to recap the problem. In the threadtest program if you have a bunch of threads creating mutexes and having them collected then get a thread that does a few forks what can happen is that the child executes atforkchild as I think the first thing it does which calls initwithstackbase which does an allocation and possible collection. Unfortunately the weaktable from the parent may be non empty and this is the only thread executing. It calls the cleanup of those mutexes of nonexistant threads some of which may be locked. If they are locked then pthread_mutex_destroy returns ebusy. Then the child exits with the abort in pthread_mutex_delete. >>>> Whether the abort is needed I dont know. In this case the error can be safely ignored. One could try to see if the owner of the mutex is still alive and not abort in that case. Otherwise if one is sure the child is going to do an exec almost immediately then disabling the collector in atforkchild could work. >>>> In the broader picture anything thats got a weak ref still active could cause problems if one thread does a fork. The weak callback could do anything. >>>> Anyway I dont know what the fix is. >>>> >>>> Peter >>> >> >> -- >> Rodney Bates >> rodney.m.bates at acm.org >> >> > -- Rodney Bates rodney.m.bates at acm.org From dragisha at m3w.org Wed Jul 9 07:04:55 2014 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 9 Jul 2014 07:04:55 +0200 Subject: [M3devel] Fwd: Fork bug In-Reply-To: <53BC447C.6060609@lcwb.coop> References: <53BB4943.4000509@lcwb.coop> <53BC447C.6060609@lcwb.coop> Message-ID: 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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: From dragisha at m3w.org Thu Jul 10 12:14:55 2014 From: dragisha at m3w.org (dragisha at m3w.org) Date: Thu, 10 Jul 2014 12:14:55 +0200 Subject: [M3devel] newest build for new machine (OSX Mavericks) Message-ID: Hi, What would be smartest way to get started with cm3 on a new box? It is AMD64_DARWIN and I would like to copy as little of my old files as possible. TIA, dd From dragisha at m3w.org Thu Jul 10 22:46:10 2014 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 10 Jul 2014 22:46:10 +0200 Subject: [M3devel] newest build for new machine (OSX Mavericks) In-Reply-To: <8C61155B-3450-42AE-9906-EDDFF324AA92@purdue.edu> References: <8C61155B-3450-42AE-9906-EDDFF324AA92@purdue.edu> Message-ID: It would be great if you can send them. Mine are pretty old. On 10 Jul 2014, at 17:17, Antony Hosking wrote: > I generally bootstrap by hand. It's been a while since I tried the automatic scripts. I do have AMD64_DARWIN binaries if you need them. > > Sent from my iPad > >> On Jul 10, 2014, at 5:14 AM, dragisha at m3w.org wrote: >> >> Hi, >> >> What would be smartest way to get started with cm3 on a new box? It is AMD64_DARWIN and I would like to copy as little of my old files as possible. >> >> TIA, >> dd -------------- 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: From danielal.benavides at bancoagrario.gov.co Fri Jul 11 00:39:41 2014 From: danielal.benavides at bancoagrario.gov.co (Daniel Alejandro Benavides Diaz) Date: Thu, 10 Jul 2014 22:39:41 +0000 Subject: [M3devel] Fwd: Fork bug In-Reply-To: References: <53BB4943.4000509@lcwb.coop> <53BC447C.6060609@lcwb.coop> Message-ID: <07BBCC4CA9881B44A4F63543096A47980D4401EF@DRG008W8SMBX014.bancoagrario.gov.co> 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 > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Fri Jul 11 06:36:29 2014 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Fri, 11 Jul 2014 00:36:29 -0400 Subject: [M3devel] Fwd: Fork bug In-Reply-To: <07BBCC4CA9881B44A4F63543096A47980D4401EF@DRG008W8SMBX014.bancoagrario.gov.co> References: <53BB4943.4000509@lcwb.coop> <53BC447C.6060609@lcwb.coop> <07BBCC4CA9881B44A4F63543096A47980D4401EF@DRG008W8SMBX014.bancoagrario.gov.co> Message-ID: <20140711043629.GB14560@topoi.pooq.com> 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 > 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 From danielal.benavides at bancoagrario.gov.co Fri Jul 11 00:31:59 2014 From: danielal.benavides at bancoagrario.gov.co (Daniel Alejandro Benavides Diaz) Date: Thu, 10 Jul 2014 22:31:59 +0000 Subject: [M3devel] Fwd: Re: Fwd: Fork bug In-Reply-To: <53BC447C.6060609@lcwb.coop> References: <53BB4943.4000509@lcwb.coop> <53BC447C.6060609@lcwb.coop> Message-ID: <07BBCC4CA9881B44A4F63543096A47980D44009E@DRG008W8SMBX014.bancoagrario.gov.co> Hi: I don't think so, that's precisely why the locking level notation was invented by Trestle' authors to cope with that complexity in the code, this allowed Trestle to be highly efficient for multiprocessors machines (among other things we need to look again for readers and writers efficiency). These two pieces of software were ESCed by Nelson and others. In that side Nelson said about this was a mistake in Java programming language design, because of the difficulty of reasoning about concurrency properties as seen in ESC experiments. If I may say add, Algol like languages excel in intelligibility, something other language families didn't make too much effort to support. In any case, I'm not for this change so don't make me do a second attempt to return to this forum :) Thanks in advance -----Mensaje original----- De: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Enviado el: Martes, 08 de Julio de 2014 02:20 p.m. Para: m3devel Asunto: [M3devel] Fwd: Re: Fwd: Fork bug Resent after 24 hours: 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. I don't remember the details off the top of my head, but there is a place in Trestle where you have to acquire a MUTEX but it is very difficult or impossible to know whether different code on the same thread already has done so. The different code isn't under your control either. Some runtime scheme to figure it out dynamically would be tantamount to, but messier than, just having a recursive MUTEX. I recall there are other places as well where similar problems arise. It would greatly simplify things when needed. The only disadvantage I can think of is there might be a case where runtime detection of a second lock attempt by the same thread would help find a bug. Maybe the RTS could have a way of setting the behavior of a specific MUTEX. On 07/03/2014 02:28 PM, Tony Hosking wrote: > I wonder if we should not move to a surrogate parent model to make this cleaner in general? > Since fork is (or should be) only used in service of creating a new process (i.e., fork + exec) then this technique would save us a lot of grief. > Thoughts? > > In the surrogate parent model, a program forks a child process at initialization time. The sole purpose of the child is to serve as a sort of "surrogate parent" for the original process should it ever need to fork another child. After initialization, the original parent can proceed to create its additional threads. When it wants to /exec/ an image, it communicates this to its child (which has remained single-threaded). The child then performs the /fork/ and /exec/ on behalf of the original process. > > > > Begin forwarded message: > >> *From: *Peter McKinna > > >> *Subject: **Fork bug* >> *Date: *July 2, 2014 at 10:30:24 PM EDT >> *To: *Antony Hosking > > >> >> Hi Tony, >> >> That fork bug on posix doesn't appear to be fixed, so just to recap the problem. In the threadtest program if you have a bunch of threads creating mutexes and having them collected then get a thread that does a few forks what can happen is that the child executes atforkchild as I think the first thing it does which calls initwithstackbase which does an allocation and possible collection. Unfortunately the weaktable from the parent may be non empty and this is the only thread executing. It calls the cleanup of those mutexes of nonexistant threads some of which may be locked. If they are locked then pthread_mutex_destroy returns ebusy. Then the child exits with the abort in pthread_mutex_delete. >> Whether the abort is needed I dont know. In this case the error can be safely ignored. One could try to see if the owner of the mutex is still alive and not abort in that case. Otherwise if one is sure the child is going to do an exec almost immediately then disabling the collector in atforkchild could work. >> In the broader picture anything thats got a weak ref still active could cause problems if one thread does a fork. The weak callback could do anything. >> Anyway I dont know what the fix is. >> >> Peter > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jul 11 07:09:42 2014 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 11 Jul 2014 07:09:42 +0200 Subject: [M3devel] Fork bug In-Reply-To: <20140711043629.GB14560@topoi.pooq.com> References: <53BB4943.4000509@lcwb.coop> <53BC447C.6060609@lcwb.coop> <07BBCC4CA9881B44A4F63543096A47980D4401EF@DRG008W8SMBX014.bancoagrario.gov.co> <20140711043629.GB14560@topoi.pooq.com> Message-ID: <2EDE2F7D-5171-4968-A27E-097DE8C544E2@m3w.org> 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 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 > 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: From dragisha at m3w.org Sat Jul 12 17:52:51 2014 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 12 Jul 2014 17:52:51 +0200 Subject: [M3devel] RT0u... Message-ID: <6EB309A4-2DCF-4B26-80E8-0F572104D748@m3w.org> new source -> compiling RTMachine.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 10: unable to find interface (RT0u) 1 error encountered Can somebody please explain this? Happens on every build path I tried till now. On CVS repo these files (RT0u.i3 & RT0u.m3) are in Attic, but they are referred from RTAllocStats.m3... -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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: From dragisha at m3w.org Sat Jul 12 22:09:55 2014 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 12 Jul 2014 22:09:55 +0200 Subject: [M3devel] RT0u... In-Reply-To: References: <6EB309A4-2DCF-4B26-80E8-0F572104D748@m3w.org> Message-ID: RT0u or RTAllocStats is dead? Checkout is clean, AFAIK. dd On 12 Jul 2014, at 21:39, Antony Hosking wrote: > That file is long dead. Do you have a clean checkout? > > Sent from my iPhone > > On Jul 12, 2014, at 10:52 AM, Dragi?a Duri? wrote: > >> new source -> compiling RTMachine.i3 >> new source -> compiling RTStack.i3 >> new source -> compiling RTAllocStats.m3 >> "../src/runtime/common/RTAllocStats.m3", line 10: unable to find interface (RT0u) >> 1 error encountered >> >> Can somebody please explain this? Happens on every build path I tried till now. On CVS repo these files (RT0u.i3 & RT0u.m3) are in Attic, but they are referred from RTAllocStats.m3... >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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: From rodney_bates at lcwb.coop Mon Jul 14 21:32:01 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 14 Jul 2014 14:32:01 -0500 Subject: [M3devel] "types" directory confusion Message-ID: <53C43031.7080208@lcwb.coop> The documentation is wrong about the location of the type-describing interfaces for instantiating generics, and they are inconsistent and incomplete in their locations. For example, the page cm3/doc/help/gen_html/libm3/src/types/Refany.i3.html claims to describe an interface located in cm3/m3-libs/libm3/src/types, but this file is actually located in cm3/m3-libs/m3core/src/types. Of these kinds of interfaces, only RealType.i3 and LongrealType.i3 are in libm3. Most/all of the rest are in m3core. I don't see an ExtendedType.i3 at all. (There are a bunch of interfaces concerning floating types, including Extended, but they contain different information. None appear to be for instantiating e.g, Table.) Do we want to consistify this? I seem to remember that there once were copies of at least some of these in both m3core/src/types and libm3/src/types. Also, does anybody know what the procedure is for regenerating the html documentation files? -- Rodney Bates rodney.m.bates at acm.org From danielal.benavides at bancoagrario.gov.co Tue Jul 15 00:51:53 2014 From: danielal.benavides at bancoagrario.gov.co (Daniel Alejandro Benavides Diaz) Date: Mon, 14 Jul 2014 22:51:53 +0000 Subject: [M3devel] Fork bug In-Reply-To: <2EDE2F7D-5171-4968-A27E-097DE8C544E2@m3w.org> References: <53BB4943.4000509@lcwb.coop> <53BC447C.6060609@lcwb.coop> <07BBCC4CA9881B44A4F63543096A47980D4401EF@DRG008W8SMBX014.bancoagrario.gov.co> <20140711043629.GB14560@topoi.pooq.com> <2EDE2F7D-5171-4968-A27E-097DE8C544E2@m3w.org> Message-ID: <07BBCC4CA9881B44A4F63543096A47981258BE8D@DRG008W8SMBX014.bancoagrario.gov.co> Hi: Don't try to make this sound like a special case, this is different type operator semantics, the language doesn?t allow that behavior and is a design error according to Nelson. Thanks in advance -----Mensaje original----- De: Dragi?a Duri? [mailto:dragisha at m3w.org] Enviado el: Viernes, 11 de Julio de 2014 12:10 a.m. Para: Hendrik Boom CC: m3devel at elegosoft.com Asunto: Re: [M3devel] Fork bug 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 > 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 >> 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 -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jul 15 08:29:48 2014 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 15 Jul 2014 08:29:48 +0200 Subject: [M3devel] "types" directory confusion In-Reply-To: <53C43031.7080208@lcwb.coop> References: <53C43031.7080208@lcwb.coop> Message-ID: <20140715082948.b516efcd9f558d689fd5492a@elegosoft.com> On Mon, 14 Jul 2014 14:32:01 -0500 "Rodney M. Bates" wrote: > The documentation is wrong about the location of the type-describing interfaces > for instantiating generics, and they are inconsistent and incomplete in their > locations. > > For example, the page cm3/doc/help/gen_html/libm3/src/types/Refany.i3.html claims > to describe an interface located in cm3/m3-libs/libm3/src/types, but this file is > actually located in cm3/m3-libs/m3core/src/types. Of these kinds of interfaces, > only RealType.i3 and LongrealType.i3 are in libm3. Most/all of the rest are in > m3core. I don't see an ExtendedType.i3 at all. > > (There are a bunch of interfaces concerning floating types, including Extended, but > they contain different information. None appear to be for instantiating e.g, Table.) > > Do we want to consistify this? I seem to remember that there once were copies > of at least some of these in both m3core/src/types and libm3/src/types. > > Also, does anybody know what the procedure is for regenerating the html > documentation files? With the latter I may be of help. Let's see... In ~/work/cm3/scripts/make-doc-dist.sh there's the following snippet: if [ "$1" = "-gen" ] ; then cd "${ROOT}/doc/help/gen_html" || exit 1 rm -f html_gen/m3db m3tohtml -v -root /usr/local/cm3/pkg `cd /usr/local/cm3/pkg && ls -d *` fi That should do it, I think. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jul 15 10:22:51 2014 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Jul 2014 08:22:51 +0000 Subject: [M3devel] "types" directory confusion In-Reply-To: <20140715082948.b516efcd9f558d689fd5492a@elegosoft.com> References: <53C43031.7080208@lcwb.coop>, <20140715082948.b516efcd9f558d689fd5492a@elegosoft.com> Message-ID: To be clear -- this was in libm3 and Tony moved it all to m3core and I trust that he had a good reason. I think he did it along with the introduction of LONGINT. - Jay > Date: Tue, 15 Jul 2014 08:29:48 +0200 > From: wagner at elegosoft.com > To: rodney.m.bates at acm.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] "types" directory confusion > > On Mon, 14 Jul 2014 14:32:01 -0500 > "Rodney M. Bates" wrote: > > > The documentation is wrong about the location of the type-describing interfaces > > for instantiating generics, and they are inconsistent and incomplete in their > > locations. > > > > For example, the page cm3/doc/help/gen_html/libm3/src/types/Refany.i3.html claims > > to describe an interface located in cm3/m3-libs/libm3/src/types, but this file is > > actually located in cm3/m3-libs/m3core/src/types. Of these kinds of interfaces, > > only RealType.i3 and LongrealType.i3 are in libm3. Most/all of the rest are in > > m3core. I don't see an ExtendedType.i3 at all. > > > > (There are a bunch of interfaces concerning floating types, including Extended, but > > they contain different information. None appear to be for instantiating e.g, Table.) > > > > Do we want to consistify this? I seem to remember that there once were copies > > of at least some of these in both m3core/src/types and libm3/src/types. > > > > Also, does anybody know what the procedure is for regenerating the html > > documentation files? > > With the latter I may be of help. Let's see... > > In ~/work/cm3/scripts/make-doc-dist.sh there's the following snippet: > > if [ "$1" = "-gen" ] ; then > cd "${ROOT}/doc/help/gen_html" || exit 1 > rm -f html_gen/m3db > m3tohtml -v -root /usr/local/cm3/pkg `cd /usr/local/cm3/pkg && ls -d *` > fi > > That should do it, I think. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Jul 16 08:38:56 2014 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Tue, 15 Jul 2014 23:38:56 -0700 Subject: [M3devel] Fwd: Fork bug In-Reply-To: <20140711043629.GB14560@topoi.pooq.com> References: <53BB4943.4000509@lcwb.coop> <53BC447C.6060609@lcwb.coop> <07BBCC4CA9881B44A4F63543096A47980D4401EF@DRG008W8SMBX014.bancoagrario.gov.co> <20140711043629.GB14560@topoi.pooq.com> Message-ID: <20140716063856.943571A20B0@async.async.caltech.edu> Hendrik Boom writes: ... >> 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. > I agree with these sentiments wholeheartedly. A link to a paper my graduate advisor wrote years ago: http://www.async.caltech.edu/~mika/Axiomatic-def.pdf Modula-3 MUTEX is a restricted form of Dijkstra's P and V operations. The proof rules in the paper are very simple but not if you allow a recursive mutex. Mika From mika at async.caltech.edu Wed Jul 23 13:45:07 2014 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 23 Jul 2014 04:45:07 -0700 Subject: [M3devel] turning off checking? Message-ID: <20140723114507.A557C1A2098@async.async.caltech.edu> Hi m3devel, Does anyone remember how to turn off... -- bounds checking -- NIL checking -- etc.... Mika From mika at async.caltech.edu Wed Jul 23 19:41:22 2014 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 23 Jul 2014 10:41:22 -0700 Subject: [M3devel] turning off checking? In-Reply-To: References: <20140723114507.A557C1A2098@async.async.caltech.edu> Message-ID: <20140723174122.406451A209C@async.async.caltech.edu> Thanks Tony... but now I am at the same question as the authors of that email exchange. How to get the option to that block of code?? Hmm... Antony Hosking writes: >Hmm, I knew once how to do this. Let me see=85 > >Here is a link that suggests how: = >https://mail.elegosoft.com/pipermail/m3devel/2007-November/000634.html > > >On Jul 23, 2014, at 6:45 AM, mika at async.caltech.edu wrote: > >> Hi m3devel, >>=20 >> Does anyone remember how to turn off... >>=20 >> -- bounds checking >>=20 >> -- NIL checking >>=20 >> -- etc.... >>=20 >> Mika From mika at async.caltech.edu Wed Jul 23 22:29:41 2014 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 23 Jul 2014 13:29:41 -0700 Subject: [M3devel] turning off checking? In-Reply-To: <9D99758A-36EA-437E-BCD7-D15D64DA0FA0@purdue.edu> References: <20140723114507.A557C1A2098@async.async.caltech.edu> <20140723174122.406451A209C@async.async.caltech.edu> <9D99758A-36EA-437E-BCD7-D15D64DA0FA0@purdue.edu> Message-ID: <20140723202941.06A481A209C@async.async.caltech.edu> Did you try it successfully? Sorry for the newbie question, but how did you quote it? I tried every alternative that came to mind (in tcsh)... Antony Hosking writes: >Looks like -D=92M3_OPTIONS=3D["NoChecks"]=92 > >On Jul 23, 2014, at 12:41 PM, mika at async.caltech.edu wrote: > >>=20 >> Thanks Tony... but now I am at the same question as the authors of = >that >> email exchange. How to get the option to that block of code?? Hmm... >>=20 >> Antony Hosking writes: >>> Hmm, I knew once how to do this. Let me see=3D85 >>>=20 >>> Here is a link that suggests how: =3D >>> = >https://mail.elegosoft.com/pipermail/m3devel/2007-November/000634.html >>>=20 >>>=20 >>> On Jul 23, 2014, at 6:45 AM, mika at async.caltech.edu wrote: >>>=20 >>>> Hi m3devel, >>>> =3D20 >>>> Does anyone remember how to turn off... >>>> =3D20 >>>> -- bounds checking >>>> =3D20 >>>> -- NIL checking >>>> =3D20 >>>> -- etc.... >>>> =3D20 >>>> Mika From mika at async.caltech.edu Thu Jul 24 12:08:33 2014 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Thu, 24 Jul 2014 03:08:33 -0700 Subject: [M3devel] turning off checking? In-Reply-To: <9D99758A-36EA-437E-BCD7-D15D64DA0FA0@purdue.edu> References: <20140723114507.A557C1A2098@async.async.caltech.edu> <20140723174122.406451A209C@async.async.caltech.edu> <9D99758A-36EA-437E-BCD7-D15D64DA0FA0@purdue.edu> Message-ID: <20140724100833.D64931A20A1@async.async.caltech.edu> I added M3_OPTIONS=["NoChecks"] to my cm3.cfg: (62)truffles:~/t/btc/hsim/gcrit/src>cm3 -x --- building in ../AMD64_LINUX --- new source -> compiling CardCritAttrTbl.i3 m3c: unknown option, "NoChecks" Fatal Error: failed compiling: I know my inner loops are littered with "CheckLoadTracedRef"... For fun, here is an example: 389 VAR p := min.priority; 390 s := min.node.succ; 391 d := min.node.sDly; 392 BEGIN 393 395 FOR i := 0 TO min.node.ns-1 DO 396 HandleFanout(p, s[i], d[i]) 397 END; 398 END; min is an object (an extended PQ element with priority of LONGREAL) node is some other object of type Node with succ and sDly being arrays. succ is a pointer to another Node. sDly is a LONGREAL. ns is used to amortize reallocations. I think you can guess what this code does (sort of). Here is the assembly---looks nasty! : /big/home/mika/t/zpy/hsim/gcrit/AMD64_LINUX/../src/ERS.m3:389 40ad05: 48 8b 85 30 ff ff ff mov -0xd0(%rbp),%rax 40ad0c: 48 8b 40 08 mov 0x8(%rax),%rax 40ad10: 48 89 45 90 mov %rax,-0x70(%rbp) /big/home/mika/t/zpy/hsim/gcrit/AMD64_LINUX/../src/ERS.m3:390 40ad14: 48 8b 85 30 ff ff ff mov -0xd0(%rbp),%rax 40ad1b: 48 8b 40 28 mov 0x28(%rax),%rax 40ad1f: 48 89 45 a8 mov %rax,-0x58(%rbp) 40ad23: 48 83 7d a8 00 cmpq $0x0,-0x58(%rbp) 40ad28: 74 34 je 40ad5e 40ad2a: 48 8b 45 a8 mov -0x58(%rbp),%rax 40ad2e: 83 e0 01 and $0x1,%eax 40ad31: 83 e0 01 and $0x1,%eax 40ad34: 84 c0 test %al,%al 40ad36: 75 26 jne 40ad5e 40ad38: 48 8b 45 a8 mov -0x58(%rbp),%rax 40ad3c: 48 83 e8 08 sub $0x8,%rax 40ad40: 48 8b 00 mov (%rax),%rax 40ad43: 48 c1 e0 29 shl $0x29,%rax 40ad47: 48 c1 e8 3f shr $0x3f,%rax 40ad4b: 83 e0 01 and $0x1,%eax 40ad4e: 84 c0 test %al,%al 40ad50: 74 0c je 40ad5e 40ad52: 48 8b 45 a8 mov -0x58(%rbp),%rax 40ad56: 48 89 c7 mov %rax,%rdi 40ad59: e8 4e 0d 0b 00 callq 4bbaac 40ad5e: 48 8b 45 a8 mov -0x58(%rbp),%rax 40ad62: 48 8b 40 28 mov 0x28(%rax),%rax 40ad66: 48 89 45 a0 mov %rax,-0x60(%rbp) 40ad6a: 48 83 7d a0 00 cmpq $0x0,-0x60(%rbp) 40ad6f: 74 34 je 40ada5 40ad71: 48 8b 45 a0 mov -0x60(%rbp),%rax 40ad75: 83 e0 01 and $0x1,%eax 40ad78: 83 e0 01 and $0x1,%eax 40ad7b: 84 c0 test %al,%al 40ad7d: 75 26 jne 40ada5 40ad7f: 48 8b 45 a0 mov -0x60(%rbp),%rax 40ad83: 48 83 e8 08 sub $0x8,%rax 40ad87: 48 8b 00 mov (%rax),%rax 40ad8a: 48 c1 e0 29 shl $0x29,%rax 40ad8e: 48 c1 e8 3f shr $0x3f,%rax 40ad92: 83 e0 01 and $0x1,%eax 40ad95: 84 c0 test %al,%al 40ad97: 74 0c je 40ada5 40ad99: 48 8b 45 a0 mov -0x60(%rbp),%rax 40ad9d: 48 89 c7 mov %rax,%rdi 40ada0: e8 07 0d 0b 00 callq 4bbaac 40ada5: 48 8b 45 a0 mov -0x60(%rbp),%rax 40ada9: 48 89 45 88 mov %rax,-0x78(%rbp) /big/home/mika/t/zpy/hsim/gcrit/AMD64_LINUX/../src/ERS.m3:391 40adad: 48 8b 85 30 ff ff ff mov -0xd0(%rbp),%rax 40adb4: 48 8b 40 28 mov 0x28(%rax),%rax 40adb8: 48 89 45 a0 mov %rax,-0x60(%rbp) 40adbc: 48 83 7d a0 00 cmpq $0x0,-0x60(%rbp) 40adc1: 74 34 je 40adf7 40adc3: 48 8b 45 a0 mov -0x60(%rbp),%rax 40adc7: 83 e0 01 and $0x1,%eax 40adca: 83 e0 01 and $0x1,%eax 40adcd: 84 c0 test %al,%al 40adcf: 75 26 jne 40adf7 40add1: 48 8b 45 a0 mov -0x60(%rbp),%rax 40add5: 48 83 e8 08 sub $0x8,%rax 40add9: 48 8b 00 mov (%rax),%rax 40addc: 48 c1 e0 29 shl $0x29,%rax 40ade0: 48 c1 e8 3f shr $0x3f,%rax 40ade4: 83 e0 01 and $0x1,%eax 40ade7: 84 c0 test %al,%al 40ade9: 74 0c je 40adf7 40adeb: 48 8b 45 a0 mov -0x60(%rbp),%rax 40adef: 48 89 c7 mov %rax,%rdi 40adf2: e8 b5 0c 0b 00 callq 4bbaac 40adf7: 48 8b 45 a0 mov -0x60(%rbp),%rax 40adfb: 48 8b 40 30 mov 0x30(%rax),%rax 40adff: 48 89 45 a8 mov %rax,-0x58(%rbp) 40ae03: 48 83 7d a8 00 cmpq $0x0,-0x58(%rbp) 40ae08: 74 34 je 40ae3e 40ae0a: 48 8b 45 a8 mov -0x58(%rbp),%rax 40ae0e: 83 e0 01 and $0x1,%eax 40ae11: 83 e0 01 and $0x1,%eax 40ae14: 84 c0 test %al,%al 40ae16: 75 26 jne 40ae3e 40ae18: 48 8b 45 a8 mov -0x58(%rbp),%rax 40ae1c: 48 83 e8 08 sub $0x8,%rax 40ae20: 48 8b 00 mov (%rax),%rax 40ae23: 48 c1 e0 29 shl $0x29,%rax 40ae27: 48 c1 e8 3f shr $0x3f,%rax 40ae2b: 83 e0 01 and $0x1,%eax 40ae2e: 84 c0 test %al,%al 40ae30: 74 0c je 40ae3e 40ae32: 48 8b 45 a8 mov -0x58(%rbp),%rax 40ae36: 48 89 c7 mov %rax,%rdi 40ae39: e8 6e 0c 0b 00 callq 4bbaac 40ae3e: 48 8b 45 a8 mov -0x58(%rbp),%rax 40ae42: 48 89 45 80 mov %rax,-0x80(%rbp) /big/home/mika/t/zpy/hsim/gcrit/AMD64_LINUX/../src/ERS.m3:394 40ae46: 48 8b 85 30 ff ff ff mov -0xd0(%rbp),%rax 40ae4d: 48 8b 40 28 mov 0x28(%rax),%rax 40ae51: 48 89 45 a8 mov %rax,-0x58(%rbp) 40ae55: 48 83 7d a8 00 cmpq $0x0,-0x58(%rbp) 40ae5a: 74 34 je 40ae90 40ae5c: 48 8b 45 a8 mov -0x58(%rbp),%rax 40ae60: 83 e0 01 and $0x1,%eax 40ae63: 83 e0 01 and $0x1,%eax 40ae66: 84 c0 test %al,%al 40ae68: 75 26 jne 40ae90 40ae6a: 48 8b 45 a8 mov -0x58(%rbp),%rax 40ae6e: 48 83 e8 08 sub $0x8,%rax 40ae72: 48 8b 00 mov (%rax),%rax 40ae75: 48 c1 e0 29 shl $0x29,%rax 40ae79: 48 c1 e8 3f shr $0x3f,%rax 40ae7d: 83 e0 01 and $0x1,%eax 40ae80: 84 c0 test %al,%al 40ae82: 74 0c je 40ae90 40ae84: 48 8b 45 a8 mov -0x58(%rbp),%rax 40ae88: 48 89 c7 mov %rax,%rdi 40ae8b: e8 1c 0c 0b 00 callq 4bbaac 40ae90: 48 8b 45 a8 mov -0x58(%rbp),%rax 40ae94: 48 83 c0 20 add $0x20,%rax 40ae98: 48 8b 00 mov (%rax),%rax 40ae9b: 48 83 e8 01 sub $0x1,%rax 40ae9f: 48 89 85 78 ff ff ff mov %rax,-0x88(%rbp) 40aea6: 48 c7 45 c8 00 00 00 movq $0x0,-0x38(%rbp) 40aead: 00 40aeae: 48 8b 85 78 ff ff ff mov -0x88(%rbp),%rax 40aeb5: 48 89 85 70 ff ff ff mov %rax,-0x90(%rbp) 40aebc: e9 f2 00 00 00 jmpq 40afb3 /big/home/mika/t/zpy/hsim/gcrit/AMD64_LINUX/../src/ERS.m3:395 40aec1: 48 8b 45 88 mov -0x78(%rbp),%rax 40aec5: 48 89 45 a8 mov %rax,-0x58(%rbp) 40aec9: 48 8b 55 c8 mov -0x38(%rbp),%rdx 40aecd: 48 8b 45 a8 mov -0x58(%rbp),%rax 40aed1: 48 83 c0 08 add $0x8,%rax 40aed5: 48 8b 00 mov (%rax),%rax 40aed8: 48 39 c2 cmp %rax,%rdx 40aedb: 72 0a jb 40aee7 40aedd: bf 62 31 00 00 mov $0x3162,%edi 40aee2: e8 50 0c 00 00 callq 40bb37 <_m3_fault> 40aee7: 48 8b 45 a8 mov -0x58(%rbp),%rax 40aeeb: 48 8b 10 mov (%rax),%rdx 40aeee: 48 8b 45 c8 mov -0x38(%rbp),%rax 40aef2: 48 c1 e0 03 shl $0x3,%rax 40aef6: 48 01 d0 add %rdx,%rax 40aef9: 48 8b 00 mov (%rax),%rax 40aefc: 48 89 45 a0 mov %rax,-0x60(%rbp) 40af00: 48 83 7d a0 00 cmpq $0x0,-0x60(%rbp) 40af05: 74 34 je 40af3b 40af07: 48 8b 45 a0 mov -0x60(%rbp),%rax 40af0b: 83 e0 01 and $0x1,%eax 40af0e: 83 e0 01 and $0x1,%eax 40af11: 84 c0 test %al,%al 40af13: 75 26 jne 40af3b 40af15: 48 8b 45 a0 mov -0x60(%rbp),%rax 40af19: 48 83 e8 08 sub $0x8,%rax 40af1d: 48 8b 00 mov (%rax),%rax 40af20: 48 c1 e0 29 shl $0x29,%rax 40af24: 48 c1 e8 3f shr $0x3f,%rax 40af28: 83 e0 01 and $0x1,%eax 40af2b: 84 c0 test %al,%al 40af2d: 74 0c je 40af3b 40af2f: 48 8b 45 a0 mov -0x60(%rbp),%rax 40af33: 48 89 c7 mov %rax,%rdi 40af36: e8 71 0b 0b 00 callq 4bbaac 40af3b: 48 8b 45 80 mov -0x80(%rbp),%rax 40af3f: 48 89 45 98 mov %rax,-0x68(%rbp) 40af43: 48 8b 55 c8 mov -0x38(%rbp),%rdx 40af47: 48 8b 45 98 mov -0x68(%rbp),%rax 40af4b: 48 83 c0 08 add $0x8,%rax 40af4f: 48 8b 00 mov (%rax),%rax 40af52: 48 39 c2 cmp %rax,%rdx 40af55: 72 0a jb 40af61 40af57: bf 62 31 00 00 mov $0x3162,%edi 40af5c: e8 d6 0b 00 00 callq 40bb37 <_m3_fault> 40af61: 48 8b 45 98 mov -0x68(%rbp),%rax 40af65: 48 8b 10 mov (%rax),%rdx 40af68: 48 8b 45 c8 mov -0x38(%rbp),%rax 40af6c: 48 c1 e0 03 shl $0x3,%rax 40af70: 48 01 d0 add %rdx,%rax 40af73: 48 8b 10 mov (%rax),%rdx 40af76: 48 8b 4d a0 mov -0x60(%rbp),%rcx 40af7a: 48 8b 45 90 mov -0x70(%rbp),%rax 40af7e: 48 8d b5 30 ff ff ff lea -0xd0(%rbp),%rsi 40af85: 49 89 f2 mov %rsi,%r10 40af88: 48 89 95 18 ff ff ff mov %rdx,-0xe8(%rbp) 40af8f: f2 0f 10 8d 18 ff ff movsd -0xe8(%rbp),%xmm1 40af96: ff 40af97: 48 89 cf mov %rcx,%rdi 40af9a: 48 89 85 18 ff ff ff mov %rax,-0xe8(%rbp) 40afa1: f2 0f 10 85 18 ff ff movsd -0xe8(%rbp),%xmm0 40afa8: ff 40afa9: e8 15 f3 ff ff callq 40a2c3 /big/home/mika/t/zpy/hsim/gcrit/AMD64_LINUX/../src/ERS.m3:394 40afae: 48 83 45 c8 01 addq $0x1,-0x38(%rbp) 40afb3: 48 8b 85 70 ff ff ff mov -0x90(%rbp),%rax 40afba: 48 3b 45 c8 cmp -0x38(%rbp),%rax 40afbe: 0f 8d fd fe ff ff jge 40aec1 Antony Hosking writes: >Looks like -D=92M3_OPTIONS=3D["NoChecks"]=92 > >On Jul 23, 2014, at 12:41 PM, mika at async.caltech.edu wrote: > >>=20 >> Thanks Tony... but now I am at the same question as the authors of = >that >> email exchange. How to get the option to that block of code?? Hmm... >>=20 >> Antony Hosking writes: >>> Hmm, I knew once how to do this. Let me see=3D85 >>>=20 >>> Here is a link that suggests how: =3D >>> = >https://mail.elegosoft.com/pipermail/m3devel/2007-November/000634.html >>>=20 >>>=20 >>> On Jul 23, 2014, at 6:45 AM, mika at async.caltech.edu wrote: >>>=20 >>>> Hi m3devel, >>>> =3D20 >>>> Does anyone remember how to turn off... >>>> =3D20 >>>> -- bounds checking >>>> =3D20 >>>> -- NIL checking >>>> =3D20 >>>> -- etc.... >>>> =3D20 >>>> Mika From rodney_bates at lcwb.coop Thu Jul 24 22:06:46 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 24 Jul 2014 15:06:46 -0500 Subject: [M3devel] turning off checking? In-Reply-To: <20140724100833.D64931A20A1@async.async.caltech.edu> References: <20140723114507.A557C1A2098@async.async.caltech.edu> <20140723174122.406451A209C@async.async.caltech.edu> <9D99758A-36EA-437E-BCD7-D15D64DA0FA0@purdue.edu> <20140724100833.D64931A20A1@async.async.caltech.edu> Message-ID: <53D16756.3020401@lcwb.coop> On 07/24/2014 05:08 AM, mika at async.caltech.edu wrote: > I added M3_OPTIONS=["NoChecks"] to my cm3.cfg: > > (62)truffles:~/t/btc/hsim/gcrit/src>cm3 -x > --- building in ../AMD64_LINUX --- > > new source -> compiling CardCritAttrTbl.i3 > m3c: unknown option, "NoChecks" > Some grepping and reading suggest this message comes from m3front/src/misc/Host.m3:158, procedure ProcessArg. This would accept "-NoChecks", note the dash. Some more poking around reveals it gets these options from Quake variables M3_OPTIONS and M3_FRONT_FLAGS. Despite the name "ProcessArgs" and the use of dashes on everything, these don't appear to be command line options, which are handled in entirely different paths. Command line "-A" looks to get converted to "-NoAsserts" and appended to M3_OPTIONS by generated Quake code, to be interpreted later. There are a few other such conversions, but nothing else starting with "-No..." > Fatal Error: failed compiling: > Snip ------- -- Rodney Bates rodney.m.bates at acm.org From mika at async.caltech.edu Sat Jul 26 13:20:48 2014 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 26 Jul 2014 04:20:48 -0700 Subject: [M3devel] small bug report Message-ID: <20140726112048.C059D1A20A1@async.async.caltech.edu> Hi m3devel, So I realized that the reason my program runs slowly is not that there are a lot of range checks, etc. (BTW, changing M3_FRONT_FLAGS in cm3.cfg did manage to turn off these checks as far as I can see, thanks!) The problem is that the garbage collector involves procedure calls whenever loading references. This is no good if you are running a tight inner loop that chases pointers all over the heap. My attempt at fixing this is to change the code to use UNTRACED REF for this particular chunk, with DISPOSE. It's a small, simple part of the code, so this is a good use case for the UNSAFE Modula-3 features. I found a bug, though: consider: TYPE Node = UNTRACED ROOT OBJECT id : Elem; np : CARDINAL := 0; pred : UNTRACED REF ARRAY OF Node; ns : CARDINAL := 0; succ : UNTRACED REF ARRAY OF Node; sDly : UNTRACED REF ARRAY OF TStamp; when : TStamp; (* max of all fanins observed *) whch : Node; (* which fanin was critical *) gen : CARDINAL := 0; (* generation of cnt *) cnt : CARDINAL; (* how many fanins are left *) END; ... nd := NEW(Node, id := el, pred := NEW(UNTRACED REF ARRAY OF Node, 1), succ := NEW(UNTRACED REF ARRAY OF Node, 1), sDly := NEW(UNTRACED REF ARRAY OF TStamp, 1), cnt := 0); <*ASSERT nd.ns = 0 *> That ASSERT fails. The code works on PM3 (FreeBSD4), as expected. (It works fine with everything being traced, and I haven't changed any code at all, no DISPOSE yet, so there "can't" be a bug in my code, at least not an unsafe one.) Basically I think the implied initializers (from the :=... in the type definition) aren't being run for UNTRACED ROOT OBJECTs. Mika From rodney_bates at lcwb.coop Sat Jul 26 18:04:21 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 26 Jul 2014 11:04:21 -0500 Subject: [M3devel] small bug report In-Reply-To: <20140726112048.C059D1A20A1@async.async.caltech.edu> References: <20140726112048.C059D1A20A1@async.async.caltech.edu> Message-ID: <53D3D185.9060108@lcwb.coop> I can't reproduce this with cm3, AMD64_LINUX. The ASSERT does not fail, and I get: Breakpoint 1, P (el=11) at ../src/Main.m3:34 34 <*ASSERT nd.ns = 0 *> Current language: auto; currently Modula-3 (m3gdb) p nd.ns $1 = 0 (m3gdb) The only things I did were to declare Elem and TStamp as CARDINAL, and put the allocator and ASSERT in a procedure, with el passed in. On 07/26/2014 06:20 AM, mika at async.caltech.edu wrote: > Hi m3devel, > > So I realized that the reason my program runs slowly is not that there > are a lot of range checks, etc. > > (BTW, changing M3_FRONT_FLAGS in cm3.cfg did manage to turn off these > checks as far as I can see, thanks!) > > The problem is that the garbage collector involves procedure calls > whenever loading references. This is no good if you are running a tight > inner loop that chases pointers all over the heap. > > My attempt at fixing this is to change the code to use UNTRACED REF for this > particular chunk, with DISPOSE. It's a small, simple part of the code, so this > is a good use case for the UNSAFE Modula-3 features. > > I found a bug, though: > > consider: > > TYPE > Node = UNTRACED ROOT OBJECT > id : Elem; > > np : CARDINAL := 0; > pred : UNTRACED REF ARRAY OF Node; > > ns : CARDINAL := 0; > succ : UNTRACED REF ARRAY OF Node; > sDly : UNTRACED REF ARRAY OF TStamp; > > when : TStamp; (* max of all fanins observed *) > whch : Node; (* which fanin was critical *) > > gen : CARDINAL := 0; (* generation of cnt *) > cnt : CARDINAL; (* how many fanins are left *) > END; > > ... > > nd := NEW(Node, > id := el, > pred := NEW(UNTRACED REF ARRAY OF Node, 1), > succ := NEW(UNTRACED REF ARRAY OF Node, 1), > sDly := NEW(UNTRACED REF ARRAY OF TStamp, 1), > cnt := 0); > <*ASSERT nd.ns = 0 *> > > That ASSERT fails. > > The code works on PM3 (FreeBSD4), as expected. (It works fine with > everything being traced, and I haven't changed any code at all, no DISPOSE > yet, so there "can't" be a bug in my code, at least not an unsafe one.) > > Basically I think the implied initializers (from the :=... in the type definition) > aren't being run for UNTRACED ROOT OBJECTs. > > Mika > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sat Jul 26 19:07:13 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 26 Jul 2014 12:07:13 -0500 Subject: [M3devel] (Not so) small bug report In-Reply-To: <53D3D185.9060108@lcwb.coop> References: <20140726112048.C059D1A20A1@async.async.caltech.edu> <53D3D185.9060108@lcwb.coop> Message-ID: <53D3E041.9040402@lcwb.coop> This bug is not exactly small. The compiler assumes allocated space is zeroed, and doesn't generate any initialization code for fields with an implicit or explicit initial value of binary zeros. This is in m3front/src/types/ObjectType.m3:773 and :814 But RTAllocator.GetUntracedObj calls CStdlib.malloc to get the space, which, according to my Harbison & Steele, does not initialize to anything. For untraced REF and untraced REF ARRAY, it calls calloc, which does zero the allocated area, so it looks like this affects only untraced OBJECT. No doubt it is an accident that my small test case got memory that happened to be zero anyway. Pm3 calls CStdlib.malloc, but then zeros the result, in all 3 untraced cases. On 07/26/2014 11:04 AM, Rodney M. Bates wrote: > I can't reproduce this with cm3, AMD64_LINUX. The ASSERT does not fail, > and I get: > > Breakpoint 1, P (el=11) at ../src/Main.m3:34 > 34 <*ASSERT nd.ns = 0 *> > Current language: auto; currently Modula-3 > (m3gdb) p nd.ns > $1 = 0 > (m3gdb) > > > The only things I did were to declare Elem and TStamp as CARDINAL, > and put the allocator and ASSERT in a procedure, with el passed in. > > On 07/26/2014 06:20 AM, mika at async.caltech.edu wrote: >> Hi m3devel, >> >> So I realized that the reason my program runs slowly is not that there >> are a lot of range checks, etc. >> >> (BTW, changing M3_FRONT_FLAGS in cm3.cfg did manage to turn off these >> checks as far as I can see, thanks!) >> >> The problem is that the garbage collector involves procedure calls >> whenever loading references. This is no good if you are running a tight >> inner loop that chases pointers all over the heap. >> >> My attempt at fixing this is to change the code to use UNTRACED REF for this >> particular chunk, with DISPOSE. It's a small, simple part of the code, so this >> is a good use case for the UNSAFE Modula-3 features. >> >> I found a bug, though: >> >> consider: >> >> TYPE >> Node = UNTRACED ROOT OBJECT >> id : Elem; >> >> np : CARDINAL := 0; >> pred : UNTRACED REF ARRAY OF Node; >> >> ns : CARDINAL := 0; >> succ : UNTRACED REF ARRAY OF Node; >> sDly : UNTRACED REF ARRAY OF TStamp; >> >> when : TStamp; (* max of all fanins observed *) >> whch : Node; (* which fanin was critical *) >> >> gen : CARDINAL := 0; (* generation of cnt *) >> cnt : CARDINAL; (* how many fanins are left *) >> END; >> >> ... >> >> nd := NEW(Node, >> id := el, >> pred := NEW(UNTRACED REF ARRAY OF Node, 1), >> succ := NEW(UNTRACED REF ARRAY OF Node, 1), >> sDly := NEW(UNTRACED REF ARRAY OF TStamp, 1), >> cnt := 0); >> <*ASSERT nd.ns = 0 *> >> >> That ASSERT fails. >> >> The code works on PM3 (FreeBSD4), as expected. (It works fine with >> everything being traced, and I haven't changed any code at all, no DISPOSE >> yet, so there "can't" be a bug in my code, at least not an unsafe one.) >> >> Basically I think the implied initializers (from the :=... in the type definition) >> aren't being run for UNTRACED ROOT OBJECTs. >> >> Mika >> > -- Rodney Bates rodney.m.bates at acm.org From estellnb at elstel.org Tue Jul 29 17:32:43 2014 From: estellnb at elstel.org (Elmar Stellnberger) Date: Tue, 29 Jul 2014 17:32:43 +0200 Subject: [M3devel] turning off checking? In-Reply-To: <53D16756.3020401@lcwb.coop> References: <20140723114507.A557C1A2098@async.async.caltech.edu> <20140723174122.406451A209C@async.async.caltech.edu> <9D99758A-36EA-437E-BCD7-D15D64DA0FA0@purdue.edu> <20140724100833.D64931A20A1@async.async.caltech.edu> <53D16756.3020401@lcwb.coop> Message-ID: <53D7BE9B.7000506@elstel.org> It would be a particularely bad idea to turn off checking as a whole for most use cases; i.e. f.i. just because there is one code snipped which does not work with these checks. It should be possible to switch of range checks i.e. integer underflow and overflow checks for a paticular code block; there could be a different switch for array index range checks and so on. Concerning the automaton simulator which I had started to port to Modula-3 last year there was one such snippet which could only be made working by an explicit type conversion to longint, applying a logical and and then converting back to integer - and that for several times. The code has become almost unreadable by the many type conversions which are basically unnecessary and degrading performance. Consequently I would really appreciate such switches on a per-code block level. Elmar Am 24.07.14 22:06, schrieb Rodney M. Bates: > > > On 07/24/2014 05:08 AM, mika at async.caltech.edu wrote: >> I added M3_OPTIONS=["NoChecks"] to my cm3.cfg: >> >> (62)truffles:~/t/btc/hsim/gcrit/src>cm3 -x >> --- building in ../AMD64_LINUX --- >> >> new source -> compiling CardCritAttrTbl.i3 >> m3c: unknown option, "NoChecks" >> > > Some grepping and reading suggest this message comes from > m3front/src/misc/Host.m3:158, > procedure ProcessArg. This would accept "-NoChecks", note the dash. > > Some more poking around reveals it gets these options from Quake > variables > M3_OPTIONS and M3_FRONT_FLAGS. > > Despite the name "ProcessArgs" and the use of dashes on everything, these > don't appear to be command line options, which are handled in entirely > different paths. Command line "-A" looks to get converted to > "-NoAsserts" > and appended to M3_OPTIONS by generated Quake code, to be interpreted > later. > There are a few other such conversions, but nothing else starting with > "-No..." > >> Fatal Error: failed compiling: >> > > Snip ------- > From estellnb at elstel.org Tue Jul 29 17:46:35 2014 From: estellnb at elstel.org (Elmar Stellnberger) Date: Tue, 29 Jul 2014 17:46:35 +0200 Subject: [M3devel] Status of CM3 In-Reply-To: <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu> References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>,

, <5385A122.4020205@marino.st> <20140528182503.087801A2095@async.async.caltech.edu> <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu> Message-ID: <53D7C1DB.9050605@elstel.org> Concerning a new release of CM3; when do you think it could become true? I would really appreciate something with qt/gtk/trestle and unicode support as currently in the repositories however all of it known to work on all platforms supported by CM3. Am 28.05.14 21:32, schrieb Tony Hosking: > What is really needed is some time and attention put in to bring the > CM3 runtime up to date with respect to advances in the field of > runtime systems (as witnessed by Java, Go, etc.): lightweight locking > ("biased" locking), cooperative GC safepoints, integration with a > modern code generator (LLVM!), on-the-fly GC (avoiding the need for > stopping the world). > > It would be wonderful to attack these, but they are also somewhat > interrelated (on-the-fly depends on per-thread safepoint handshakes, > biased locking requires compiler work, etc.). So they cannot be > simply carved off independently. > > On May 28, 2014, at 2:25 PM, mika at async.caltech.edu > wrote: Modula-3 with llvm-backend? Isn`t that just a far fetched dream? I believe it would be a lot of work, nonetheless. -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Tue Jul 29 19:41:53 2014 From: estellnb at elstel.org (Elmar Stellnberger) Date: Tue, 29 Jul 2014 19:41:53 +0200 Subject: [M3devel] Status of CM3 In-Reply-To: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>,

, <5385A122.4020205@marino.st> <20140528182503.087801A2095@async.async.caltech.edu> <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu> <53D7C1DB.9050605@elstel.org> Message-ID: <53D7DCE1.5050901@elstel.org> Why not propose it for a Gg Summer of Code*, then? I would as well not be insdisposed to join some effort on CM3 in the future (however this year, not); nonetheless I can not / do not want to afford such an engagement without any income. Perhaps there are even some more compelling subjects we could find. * Though I am not sure on what it will take for you to do so I would believe it should not harm to get some support by (additional) funding. Am 29.07.14 18:13, schrieb Antony Hosking: > No, not really. > I don?t think it would be too much work. Just time that I don?t seem > to have? :-( > > On Jul 29, 2014, at 10:46 AM, Elmar Stellnberger > > wrote: > >> Isn`t that just a far fetched dream? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 3 21:28:30 2014 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 3 Jul 2014 15:28:30 -0400 Subject: [M3devel] Fwd: Fork bug References: Message-ID: I wonder if we should not move to a surrogate parent model to make this cleaner in general? Since fork is (or should be) only used in service of creating a new process (i.e., fork + exec) then this technique would save us a lot of grief. Thoughts? In the surrogate parent model, a program forks a child process at initialization time. The sole purpose of the child is to serve as a sort of "surrogate parent" for the original process should it ever need to fork another child. After initialization, the original parent can proceed to create its additional threads. When it wants to exec an image, it communicates this to its child (which has remained single-threaded). The child then performs the fork and exec on behalf of the original process. Begin forwarded message: > From: Peter McKinna > Subject: Fork bug > Date: July 2, 2014 at 10:30:24 PM EDT > To: Antony Hosking > > Hi Tony, > > That fork bug on posix doesn't appear to be fixed, so just to recap the problem. In the threadtest program if you have a bunch of threads creating mutexes and having them collected then get a thread that does a few forks what can happen is that the child executes atforkchild as I think the first thing it does which calls initwithstackbase which does an allocation and possible collection. Unfortunately the weaktable from the parent may be non empty and this is the only thread executing. It calls the cleanup of those mutexes of nonexistant threads some of which may be locked. If they are locked then pthread_mutex_destroy returns ebusy. Then the child exits with the abort in pthread_mutex_delete. > Whether the abort is needed I dont know. In this case the error can be safely ignored. One could try to see if the owner of the mutex is still alive and not abort in that case. Otherwise if one is sure the child is going to do an exec almost immediately then disabling the collector in atforkchild could work. > In the broader picture anything thats got a weak ref still active could cause problems if one thread does a fork. The weak callback could do anything. > Anyway I dont know what the fix is. > > Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 3 23:09:52 2014 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 3 Jul 2014 17:09:52 -0400 Subject: [M3devel] Fork bug In-Reply-To: References: