Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #157279 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2020-12-15 13:57 -0800 |
| Last post | 2020-12-21 22:17 +0100 |
| Articles | 20 on this page of 300 — 18 participants |
Back to article view | Back to comp.lang.c
A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-15 13:57 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-16 02:11 +0300
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 01:05 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 10:48 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 04:16 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 17:04 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 16:06 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-17 15:26 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-17 19:32 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-17 21:12 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-17 13:10 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 11:35 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 06:05 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 15:28 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 08:49 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 18:24 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 10:31 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 16:53 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 19:33 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 11:06 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:45 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 11:55 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:08 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:09 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-18 15:39 -0500
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:55 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 17:05 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 17:12 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:41 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 10:13 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:28 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-19 11:35 -0500
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:45 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-19 13:26 -0500
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 11:31 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 20:41 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 19:57 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 21:05 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 20:26 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:59 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 15:23 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 17:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 17:21 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 20:13 +0000
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 17:37 +0000
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 16:26 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-25 00:55 +0000
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 12:10 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:56 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 14:01 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 16:32 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 07:42 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 16:07 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:38 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 17:25 +0100
Re: A defer mechanism for C Christian Hanné <the.hanne@gmail.com> - 2020-12-20 17:46 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 09:07 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 18:43 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:45 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 10:11 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-20 14:58 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 08:58 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:41 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 18:45 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 20:25 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-20 22:34 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 20:52 +0100
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-20 12:37 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 08:42 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 09:19 -0500
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-21 10:18 -0500
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 11:06 -0500
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 13:09 -0500
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:13 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 13:18 -0500
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:26 -0700
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-24 00:47 -0500
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-24 00:59 -0500
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:25 -0700
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-21 14:23 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-22 09:58 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 04:57 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 04:19 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-27 11:24 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-28 22:45 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-29 00:33 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-29 11:31 -0500
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-29 17:24 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-29 18:43 +0100
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-29 11:32 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 03:34 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-29 21:06 -0500
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-29 20:40 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 02:56 -0800
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:22 -0700
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-24 02:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-24 06:49 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-24 03:16 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-24 13:38 +0100
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-24 14:37 -0800
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-25 11:39 -0500
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-26 22:34 -0800
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-26 22:48 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-27 08:51 -0500
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-24 22:50 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 09:52 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 09:18 -0800
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 09:32 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:55 +0100
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-24 14:16 -0800
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-17 22:05 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 11:42 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 05:53 -0800
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-18 19:40 +0000
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 05:19 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 11:01 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 03:45 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 13:25 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 06:26 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 15:40 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 07:05 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 16:13 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 16:21 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 17:06 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 08:57 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 19:43 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-16 12:05 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 14:26 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 15:57 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 19:49 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 11:33 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 13:05 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-17 01:52 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 10:59 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 20:47 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-17 19:58 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 21:56 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:03 +0000
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 12:30 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:16 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:39 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 13:44 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:51 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:33 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 06:54 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 13:28 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:14 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:16 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 16:19 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 17:26 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 17:07 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 18:18 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 18:34 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:40 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 21:16 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 22:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 21:50 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 23:25 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 01:01 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:47 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 02:45 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 12:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 13:33 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 20:24 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:28 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:05 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 21:55 -0800
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:26 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:28 +0100
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:38 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:51 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-25 20:00 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 12:19 +0100
Re: A defer mechanism for C Öö Tiib <ootiib@hot.ee> - 2020-12-26 19:10 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-27 05:28 +0100
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:42 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:52 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-26 02:29 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 12:11 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-26 09:33 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 18:50 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-26 07:40 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:36 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 17:49 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:39 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 16:25 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 01:55 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 23:58 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:16 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:05 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 18:33 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:55 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-18 19:10 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 16:47 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:22 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 07:09 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 07:25 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 08:02 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:55 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 21:58 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 23:05 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:40 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 22:59 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:10 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 22:46 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:46 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:00 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 10:59 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 11:12 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 02:18 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 16:25 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 19:24 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 09:07 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 22:36 +0300
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-19 15:54 -0500
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-20 01:21 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-20 15:22 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 11:53 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 11:55 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 12:07 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 03:38 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 01:40 +0000
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:00 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:02 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:22 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:43 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 12:34 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:11 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 17:22 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:08 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:26 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:36 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:54 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 22:12 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 15:13 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 12:45 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 16:25 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 13:38 +0000
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 09:26 -0500
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 20:30 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 21:41 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-16 21:02 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 07:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:14 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 19:25 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:38 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:44 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 02:07 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 00:51 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:51 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 06:15 -0800
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 06:25 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:58 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 18:43 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:56 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:55 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:52 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 00:40 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:46 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 20:22 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 21:31 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 22:27 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 09:36 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-21 21:02 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 22:24 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 13:07 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-16 18:35 -0800
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-17 04:08 +0000
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 23:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 07:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-16 20:29 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-17 01:26 +0300
Re: A defer mechanism for C fir <profesor.fir@gmail.com> - 2020-12-21 05:02 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 15:03 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 06:36 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 16:51 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:17 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:22 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:36 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:40 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:46 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 18:04 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 10:57 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 20:10 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 11:39 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 20:48 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 21:08 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 21:34 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 19:15 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:26 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 19:45 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 20:15 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 18:28 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 20:49 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 22:17 +0100
Page 6 of 15 — ← Prev page 1 … 4 5 [6] 7 8 … 15 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-24 03:16 -0800 |
| Message-ID | <b870c173-b625-4700-bed9-fd2f23d1cbfen@googlegroups.com> |
| In reply to | #157679 |
On Thursday, 24 December 2020 at 05:49:27 UTC, Bonita Montero wrote: > >> Forget it, a malloc()-implementation without free isn't a > >> malloc()-implementation. > > > How would it be possible to detect, from external behavior, that free() > > was a no-op? > > C requires a free() that frees the memory. > Depends what you mean. If you are implementing a standard library for a hosted environment, then there's a strong argument that free as a no-op is non-conforming. However many C systems don't have a malloc() / free() library provided. If you write your own memory allocation system, you don't have to provide a free(), but you might reasonably call the allocation system malloc(). As for free() as a no-op, that might be to allow for future extension, though I will admit that you're getting into the realms of bad and confusing programming guidelines here. malloc() is trivial to implement unless there is also a free() which can be called on any allocated block in any order.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-24 13:38 +0100 |
| Message-ID | <rs223s$2o5$1@dont-email.me> |
| In reply to | #157681 |
> Depends what you mean. If you are implementing a standard library for > a hosted environment, then there's a strong argument that free as a > no-op is non-conforming. # 7.20.3.2 The free function # ... # The free function causes the space pointed to by ptr to be # deallocated, that is, made available for further allocation
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-12-24 14:37 -0800 |
| Message-ID | <rs3575$1ucl$1@gioia.aioe.org> |
| In reply to | #157679 |
On 12/23/2020 9:49 PM, Bonita Montero wrote: >>> Forget it, a malloc()-implementation without free isn't a >>> malloc()-implementation. > >> How would it be possible to detect, from external behavior, that free() >> was a no-op? > > C requires a free() that frees the memory. > Well, a free can be a no-op in a pure region allocator. I am not sure if this breaks some C rule.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-12-25 11:39 -0500 |
| Message-ID | <rs54jm$ru2$1@dont-email.me> |
| In reply to | #157712 |
On 12/24/20 5:37 PM, Chris M. Thomasson wrote: > On 12/23/2020 9:49 PM, Bonita Montero wrote: >>>> Forget it, a malloc()-implementation without free isn't a >>>> malloc()-implementation. >> >>> How would it be possible to detect, from external behavior, that free() >>> was a no-op? >> >> C requires a free() that frees the memory. >> > > Well, a free can be a no-op in a pure region allocator. I am not sure if > this breaks some C rule. It violates the specification for free(): "The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation." (7.22.3.3p2). It doesn't say how soon the memory must be available for further allocation, but an implementation of free() for which it never becomes available is clearly in violation. However, it's only the observable behavior that matters as far as conformance is concerned. Since the standard never defines any situation in which calls to malloc(), calloc(), realloc() or aligned_alloc() are required to be successful, it's not possible to distinguish an implementation of free() that is non-conforming because it doesn't meet this requirement from a conforming implementation where malloc() fails for some other reason.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-12-26 22:34 -0800 |
| Message-ID | <rs99u8$14el$1@gioia.aioe.org> |
| In reply to | #157747 |
On 12/25/2020 8:39 AM, James Kuyper wrote: > On 12/24/20 5:37 PM, Chris M. Thomasson wrote: >> On 12/23/2020 9:49 PM, Bonita Montero wrote: >>>>> Forget it, a malloc()-implementation without free isn't a >>>>> malloc()-implementation. >>> >>>> How would it be possible to detect, from external behavior, that free() >>>> was a no-op? >>> >>> C requires a free() that frees the memory. >>> >> >> Well, a free can be a no-op in a pure region allocator. I am not sure if >> this breaks some C rule. > > It violates the specification for free(): "The free function causes the > space pointed to by ptr to be deallocated, that is, made available for > further allocation." (7.22.3.3p2). It doesn't say how soon the memory > must be available for further allocation, but an implementation of > free() for which it never becomes available is clearly in violation. Yup. That's it. > However, it's only the observable behavior that matters as far as > conformance is concerned. Since the standard never defines any situation > in which calls to malloc(), calloc(), realloc() or aligned_alloc() are > required to be successful, it's not possible to distinguish an > implementation of free() that is non-conforming because it doesn't meet > this requirement from a conforming implementation where malloc() fails > for some other reason. This brings me back to a time where I had to tell people that using a garbage collector is basically undefined behavior in C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-12-26 22:48 -0800 |
| Message-ID | <rs9an6$1cp4$1@gioia.aioe.org> |
| In reply to | #157807 |
On 12/26/2020 10:34 PM, Chris M. Thomasson wrote: > On 12/25/2020 8:39 AM, James Kuyper wrote: >> On 12/24/20 5:37 PM, Chris M. Thomasson wrote: >>> On 12/23/2020 9:49 PM, Bonita Montero wrote: >>>>>> Forget it, a malloc()-implementation without free isn't a >>>>>> malloc()-implementation. >>>> >>>>> How would it be possible to detect, from external behavior, that >>>>> free() >>>>> was a no-op? >>>> >>>> C requires a free() that frees the memory. >>>> >>> >>> Well, a free can be a no-op in a pure region allocator. I am not sure if >>> this breaks some C rule. >> >> It violates the specification for free(): "The free function causes the >> space pointed to by ptr to be deallocated, that is, made available for >> further allocation." (7.22.3.3p2). It doesn't say how soon the memory >> must be available for further allocation, but an implementation of >> free() for which it never becomes available is clearly in violation. > > Yup. That's it. > > >> However, it's only the observable behavior that matters as far as >> conformance is concerned. Since the standard never defines any situation >> in which calls to malloc(), calloc(), realloc() or aligned_alloc() are >> required to be successful, it's not possible to distinguish an >> implementation of free() that is non-conforming because it doesn't meet >> this requirement from a conforming implementation where malloc() fails >> for some other reason. > > This brings me back to a time where I had to tell people that using a > garbage collector is basically undefined behavior in C. I have also seen cases of deferred frees. Where malloc could fail, because a large batch of deferred frees simply has not had the time to run yet in a special "deallocation" thread, to actually deallocate things. They would eventually run, but on their own time, so to speak. So free was not a no-op, it just queued the free for deallocation at a later time. This is where somebody tried to create their own malloc/free. I suggested to use a so called "my_malloc" and "my_free" and clearly define whats going on and just leave malloc/free alone!
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-27 08:51 -0500 |
| Message-ID | <mj0GH.17914$rY1.8853@fx40.iad> |
| In reply to | #157807 |
On 12/27/20 1:34 AM, Chris M. Thomasson wrote: > On 12/25/2020 8:39 AM, James Kuyper wrote: >> On 12/24/20 5:37 PM, Chris M. Thomasson wrote: >>> On 12/23/2020 9:49 PM, Bonita Montero wrote: >>>>>> Forget it, a malloc()-implementation without free isn't a >>>>>> malloc()-implementation. >>>> >>>>> How would it be possible to detect, from external behavior, that >>>>> free() >>>>> was a no-op? >>>> >>>> C requires a free() that frees the memory. >>>> >>> >>> Well, a free can be a no-op in a pure region allocator. I am not sure if >>> this breaks some C rule. >> >> It violates the specification for free(): "The free function causes the >> space pointed to by ptr to be deallocated, that is, made available for >> further allocation." (7.22.3.3p2). It doesn't say how soon the memory >> must be available for further allocation, but an implementation of >> free() for which it never becomes available is clearly in violation. > > Yup. That's it. > > >> However, it's only the observable behavior that matters as far as >> conformance is concerned. Since the standard never defines any situation >> in which calls to malloc(), calloc(), realloc() or aligned_alloc() are >> required to be successful, it's not possible to distinguish an >> implementation of free() that is non-conforming because it doesn't meet >> this requirement from a conforming implementation where malloc() fails >> for some other reason. > > This brings me back to a time where I had to tell people that using a > garbage collector is basically undefined behavior in C. But there is no prohibition from the IMPLEMENTATION using what the Standard defines as 'Undefined Behavior' to do what it wants. After all, the implementation always has the option to define what the Standard doesn't to do what it wants. Now, the biggest problem with an implementation using garbage collection is that there are defined behaviors that allow a program to remove all references in memory to malloced block of memory, and then bring it back, so the implementation needs something better than the simple garbage collection to reclaim memory.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-24 22:50 +0000 |
| Message-ID | <20201224144813.574@kylheku.com> |
| In reply to | #157679 |
On 2020-12-24, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Forget it, a malloc()-implementation without free isn't a >>> malloc()-implementation. > >> How would it be possible to detect, from external behavior, that free() >> was a no-op? > > C requires a free() that frees the memory. Firstly, freeing memory is not actually required for an implementation to be ISO C conforming. It's not even required for an implementation to be useful. Some programs don't use dynamic memory at all, and some kinds of programs use dynamic memory only to allocate some fixed, persistent objects that last until the program terminates (avoiding performing allocations in service loops or proportional to inputs and whatnot). Lastly, free can be a no-op when there is some underlying garbage collector, along the lines of the known Boehm implementation. Memory is still freed, just not by the free function.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-25 09:52 +0100 |
| Message-ID | <rs499b$mck$1@dont-email.me> |
| In reply to | #157715 |
> Firstly, freeing memory is not actually required for an implementation to be ISO > C conforming. # 7.20.3.2 The free function # ... # The free function causes the space pointed to by ptr to be # deallocated, that is, made available for further allocation
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-19 09:18 -0800 |
| Message-ID | <606dbdae-538d-4269-af75-7f7703919b95n@googlegroups.com> |
| In reply to | #157472 |
On Saturday, 19 December 2020 at 16:05:54 UTC, David Brown wrote:
> On 18/12/2020 21:39, Richard Damon wrote:
> > On 12/18/20 11:49 AM, Malcolm McLean wrote:
> >> The code would be something like
> >>
> >> class Mutex
> >> {
> >> static bool aquired = false;
> >>
> >> Mutex()
> >> {
> >> while (acquired)
> >> yield();
> >> disable_interrupts();
> >> acquired = true;
> >> enable_interrupts();
> >> }
> >> ~Mutex()
> >> {
> >> disable_interrupts();
> >> acquired = false;
> >> enable_interrupts();
> >> }
> >> }
> >>
> >
> > Looking at this code, my biggest concern is this seems to have a race
> > between the checking that the mutex isn't held by anyone else, and the
> > claiming of it.
> >
>
> That is certainly an issue - but it is not the biggest problem. Nor is
> the fact that it won't work on a multi-core system (since disabling
> interrupts does not affect other cores).
>
> What do you think will happen on a "yield()" ?
>
> (I'm assuming that "yield()" is supposed to do what yield functions
> normally do. This is Malcolm's code, however, and along with
> Malcolm-mutexes we could be talking about Malcolm-yield, and
> Malcolm-interrupts, to extend the existing vocabulary of
> Malcolm-functions, Malcolm-arrays, and other Malcolm specific terminology.)
>
> On a "yield()", if there is another thread of the same priority in the
> runable state, the current thread will be paused and the new one will
> start. If that's the thread that currently holds the mutex, all is well
> and good. (Baring the race condition.)
>
> But if the thread that holds the mutex is a lower priority, it will not
> be scheduled after the yield() - even if it is runable. The current
> thread will simply continue to run, in a tight loop, waiting for the
> acquired flag to be released. Deadlock.
>
> Mutexes must be implemented as part of the operating system, in
> cooperation with the scheduler. (Or they can be implemented on top of
> other primitives that are part of the OS, such as queues.) You can't
> make them like Malcolm is trying to do here - even if you are talking
> about a single global lock rather than mutexes.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-19 09:32 -0800 |
| Message-ID | <9fa70e73-d85b-4eb5-8d94-ad2c7d7de771n@googlegroups.com> |
| In reply to | #157472 |
On Saturday, 19 December 2020 at 16:05:54 UTC, David Brown wrote:
> On 18/12/2020 21:39, Richard Damon wrote:
> > On 12/18/20 11:49 AM, Malcolm McLean wrote:
> >> The code would be something like
> >>
> >> class Mutex
> >> {
> >> static bool aquired = false;
> >>
> >> Mutex()
> >> {
> >> while (acquired)
> >> yield();
> >> disable_interrupts();
> >> acquired = true;
> >> enable_interrupts();
> >> }
> >> ~Mutex()
> >> {
> >> disable_interrupts();
> >> acquired = false;
> >> enable_interrupts();
> >> }
> >> }
> >>
> >
> > Looking at this code, my biggest concern is this seems to have a race
> > between the checking that the mutex isn't held by anyone else, and the
> > claiming of it.
> >
>
> That is certainly an issue - but it is not the biggest problem. Nor is
> the fact that it won't work on a multi-core system (since disabling
> interrupts does not affect other cores).
>
> What do you think will happen on a "yield()" ?
>
> (I'm assuming that "yield()" is supposed to do what yield functions
> normally do. This is Malcolm's code, however, and along with
> Malcolm-mutexes we could be talking about Malcolm-yield, and
> Malcolm-interrupts, to extend the existing vocabulary of
> Malcolm-functions, Malcolm-arrays, and other Malcolm specific terminology.)
>
> On a "yield()", if there is another thread of the same priority in the
> runable state, the current thread will be paused and the new one will
> start. If that's the thread that currently holds the mutex, all is well
> and good. (Baring the race condition.)
>
> But if the thread that holds the mutex is a lower priority, it will not
> be scheduled after the yield() - even if it is runable. The current
> thread will simply continue to run, in a tight loop, waiting for the
> acquired flag to be released. Deadlock.
>
> Mutexes must be implemented as part of the operating system, in
> cooperation with the scheduler. (Or they can be implemented on top of
> other primitives that are part of the OS, such as queues.) You can't
> make them like Malcolm is trying to do here - even if you are talking
> about a single global lock rather than mutexes.
>
The code is based on dim and distant memories of a real system which was a
games console. I programmed it back inthe 1990s.
Asfar as I remeber, yield() ceded priority. The top priority thread could yield,
it wasn't a no-op as you are implying.
But I can't remember all the details. It is entirely possible that if you has three
threads then, if the top prority thread yielded, the second priority thread would
get the processor, then it would yield, returning control to the top priority
thread, which would yield and give control to the second priority thread,
and the third priority thread would never get a look in. That would be
a broken system, but you can get broken systems in real life.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-19 18:55 +0100 |
| Message-ID | <rrleqs$hpb$1@dont-email.me> |
| In reply to | #157479 |
On 19/12/2020 18:32, Malcolm McLean wrote:
> On Saturday, 19 December 2020 at 16:05:54 UTC, David Brown wrote:
>> On 18/12/2020 21:39, Richard Damon wrote:
>>> On 12/18/20 11:49 AM, Malcolm McLean wrote:
>>>> The code would be something like
>>>>
>>>> class Mutex
>>>> {
>>>> static bool aquired = false;
>>>>
>>>> Mutex()
>>>> {
>>>> while (acquired)
>>>> yield();
>>>> disable_interrupts();
>>>> acquired = true;
>>>> enable_interrupts();
>>>> }
>>>> ~Mutex()
>>>> {
>>>> disable_interrupts();
>>>> acquired = false;
>>>> enable_interrupts();
>>>> }
>>>> }
>>>>
>>>
>>> Looking at this code, my biggest concern is this seems to have a race
>>> between the checking that the mutex isn't held by anyone else, and the
>>> claiming of it.
>>>
>>
>> That is certainly an issue - but it is not the biggest problem. Nor is
>> the fact that it won't work on a multi-core system (since disabling
>> interrupts does not affect other cores).
>>
>> What do you think will happen on a "yield()" ?
>>
>> (I'm assuming that "yield()" is supposed to do what yield functions
>> normally do. This is Malcolm's code, however, and along with
>> Malcolm-mutexes we could be talking about Malcolm-yield, and
>> Malcolm-interrupts, to extend the existing vocabulary of
>> Malcolm-functions, Malcolm-arrays, and other Malcolm specific terminology.)
>>
>> On a "yield()", if there is another thread of the same priority in the
>> runable state, the current thread will be paused and the new one will
>> start. If that's the thread that currently holds the mutex, all is well
>> and good. (Baring the race condition.)
>>
>> But if the thread that holds the mutex is a lower priority, it will not
>> be scheduled after the yield() - even if it is runable. The current
>> thread will simply continue to run, in a tight loop, waiting for the
>> acquired flag to be released. Deadlock.
>>
>> Mutexes must be implemented as part of the operating system, in
>> cooperation with the scheduler. (Or they can be implemented on top of
>> other primitives that are part of the OS, such as queues.) You can't
>> make them like Malcolm is trying to do here - even if you are talking
>> about a single global lock rather than mutexes.
>>
> The code is based on dim and distant memories of a real system which was a
> games console. I programmed it back inthe 1990s.
I think your memories are too distant here. At the very least, you are
missing some vital points.
>
> Asfar as I remeber, yield() ceded priority. The top priority thread could yield,
> it wasn't a no-op as you are implying.
"yield()" does not normally change the priority of a thread or task. It
informs the OS that the thread does not need the cpu at the time,
allowing other runable threads of the same priority to run immediately.
For time-sliced systems it avoids wasted busy-waiting time, and for
cooperative scheduling of equal priority tasks, it avoids having a
time-consuming task hog the processor for too long.
>
> But I can't remember all the details. It is entirely possible that if you has three
> threads then, if the top prority thread yielded, the second priority thread would
> get the processor, then it would yield, returning control to the top priority
> thread, which would yield and give control to the second priority thread,
> and the third priority thread would never get a look in. That would be
> a broken system, but you can get broken systems in real life.
>
If you have a high priority thread that is runable, then neither lower
priority thread should be run (on that cpu) regardless of calls to
yield(). Anything else is broken - it mocks the concept of "priority".
Some schedulers temporary raise the priority of long-waiting tasks so
that they don't get stranded forever even on a busy system - then they
become the highest priority runable tasks for a bit. Many schedulers
will also raise the priority of a task that owns a mutex, if another
higher priority task is waiting for that same mutex (thus avoiding
priority inversion problems). Again, that does not affect the principle
of the highest priority runable task always being the one that runs.
And it is because of such features that mutexes are made as part of the
OS, not thrown together in user code.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-12-24 14:16 -0800 |
| Message-ID | <rs33va$1fv5$1@gioia.aioe.org> |
| In reply to | #157382 |
On 12/18/2020 2:35 AM, David Brown wrote: [...] > The C++ method is easier to debug because it is less likely that you > will have an error in the first place. The challenge to debugging locks > and threaded code is not the obvious stuff where you've forgotten to put > an unlock in simple code like this - [...] I happen to agree here. Scoped locking is convenient. Have seen a lot of errors in some rather cryptic C and ASM code where a specific path forgot to unlock a mutex or a spinlock! The fun part is when its in a odd conditional that rarely gets hit during execution of the program. ;^o Btw, I need to read this whole thread. For some reason, I have missed it. Just looking at it now. On Christmas Eve on all days! Well, programming on Christmas is hyper nerd? ;^)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-17 22:05 +0000 |
| Message-ID | <877dpg142r.fsf@bsb.me.uk> |
| In reply to | #157355 |
David Brown <david.brown@hesbynett.no> writes: > On 17/12/2020 20:32, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 16/12/2020 17:06, Ben Bacarisse wrote: >>>> David Brown <david.brown@hesbynett.no> writes: <cut> >>>>> It looks roughly like gcc's "cleanup" attribute, in that it lets you >>>>> execute code when a variable goes out of scope. >>>> >>>> But not quite. In the example given, the mutex mtx is not declared in >>>> the block so it's unlockingcan't be linked to the scope of mtx. And in >>>> general you can't unlock a mutex at the end of it's lifetime, only after >>>> a successful lock by the same thread. >>> >>> There are no doubt other differences. (I don't know the ordering of gcc >>> cleanup functions when multiple variables go out of scope at the same >>> time.) And yes, extra effort is needed for a gcc cleanup function to >>> handle the details around freeing the mutex. >> >> Is it just details? Unlocking a mutex is not an action associated with >> the object's lifetime so gcc's cleanup mechanism seems to be the wrong >> thing. > > In C++, a perfectly good way to handle mutexes is with a "lock" class - > constructing the class object locks the mutex, and destructing it > unlocks it. gcc's cleanup is the closest you get to a destructor in C > (with gcc extensions). Note that the cleanup is associated with the > lifetime of a lock object on the mutex, not the mutex itself. Sure, but now I'm not sure what your point is here. Are you suggesting a gcc-C solution using a lock struct? I don't think that a bad way to do it, but it much more involved that the "defer" example that was posted. > (I'm not suggesting that using a cleanup function, or a defer, is > necessarily a good way to use a mutex in C.) My point is the gcc's "cleanup" does not seem to be quite up to the task in the way that the proposed "defer" is. You appeared to be saying that it was only some details that separated them, but that might be down to what constitutes a detail for you. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-18 11:42 +0100 |
| Message-ID | <rri122$889$1@dont-email.me> |
| In reply to | #157369 |
On 17/12/2020 23:05, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 17/12/2020 20:32, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 16/12/2020 17:06, Ben Bacarisse wrote: >>>>> David Brown <david.brown@hesbynett.no> writes: > <cut> >>>>>> It looks roughly like gcc's "cleanup" attribute, in that it lets you >>>>>> execute code when a variable goes out of scope. >>>>> >>>>> But not quite. In the example given, the mutex mtx is not declared in >>>>> the block so it's unlockingcan't be linked to the scope of mtx. And in >>>>> general you can't unlock a mutex at the end of it's lifetime, only after >>>>> a successful lock by the same thread. >>>> >>>> There are no doubt other differences. (I don't know the ordering of gcc >>>> cleanup functions when multiple variables go out of scope at the same >>>> time.) And yes, extra effort is needed for a gcc cleanup function to >>>> handle the details around freeing the mutex. >>> >>> Is it just details? Unlocking a mutex is not an action associated with >>> the object's lifetime so gcc's cleanup mechanism seems to be the wrong >>> thing. >> >> In C++, a perfectly good way to handle mutexes is with a "lock" class - >> constructing the class object locks the mutex, and destructing it >> unlocks it. gcc's cleanup is the closest you get to a destructor in C >> (with gcc extensions). Note that the cleanup is associated with the >> lifetime of a lock object on the mutex, not the mutex itself. > > Sure, but now I'm not sure what your point is here. Are you suggesting > a gcc-C solution using a lock struct? I don't think that a bad way to > do it, but it much more involved that the "defer" example that was > posted. > >> (I'm not suggesting that using a cleanup function, or a defer, is >> necessarily a good way to use a mutex in C.) > > My point is the gcc's "cleanup" does not seem to be quite up to the task > in the way that the proposed "defer" is. You appeared to be saying that > it was only some details that separated them, but that might be down to > what constitutes a detail for you. > I'm saying that gcc's cleanup can be used to implement the same things that are shown in the "defer" example. Yes, I agree that using it for a mutex is a more complicated, while using it for "free" is quite straightforward. It looks like the "defer" idea has all sorts of additional features not shown in this example, but for this kind of common case I think you can use "cleanup" to get code that has the same kind of source structure as the "defer" example. In other words, if a programmer thinks it is clearer to write C code with automatic release of resources at the end of the lifetime of controlling local objects, then they can do so today using gcc "cleanup". A major overhaul of C's language structure and code flow is not needed.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-18 05:53 -0800 |
| Message-ID | <20efd8ae-e2b4-47d1-bd69-0d4b0c106d21n@googlegroups.com> |
| In reply to | #157383 |
On Friday, December 18, 2020 at 7:42:25 AM UTC-3, David Brown wrote:
...
> In other words, if a programmer thinks it is clearer to write C code
> with automatic release of resources at the end of the lifetime of
> controlling local objects, then they can do so today using gcc
> "cleanup". A major overhaul of C's language structure and code flow is
> not needed.
A sample to demonstrate what I was talking about.. (no capture in gcc cleanup)
This is one case where destructor or gcc cleanup does not cover alone, c++ requires
an extra scope guard object.
/*dummy allocator just to show the point..*/
struct allocator { int dummy; };
void* allocator_alloc(struct allocator* allocator, int bytes) { return malloc(bytes);}
void* allocator_free(struct allocator* allocator, void* p) { free(p); }
void* allocator_destroy(struct allocator* allocator){ }
int main() {
struct allocator allocator = { 0 };
/* I am using my if + defer suggestion */
if (void* p = allocator_alloc(&allocator, 1);
p;
allocator_free(&allocator, p))
{
// using p
}
allocator_destroy(&allocator);
}
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-18 19:40 +0000 |
| Message-ID | <87tusiykap.fsf@bsb.me.uk> |
| In reply to | #157383 |
David Brown <david.brown@hesbynett.no> writes: > On 17/12/2020 23:05, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 17/12/2020 20:32, Ben Bacarisse wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>> >>>>> On 16/12/2020 17:06, Ben Bacarisse wrote: >>>>>> David Brown <david.brown@hesbynett.no> writes: >> <cut> >>>>>>> It looks roughly like gcc's "cleanup" attribute, in that it lets you >>>>>>> execute code when a variable goes out of scope. >>>>>> >>>>>> But not quite. In the example given, the mutex mtx is not declared in >>>>>> the block so it's unlockingcan't be linked to the scope of mtx. And in >>>>>> general you can't unlock a mutex at the end of it's lifetime, only after >>>>>> a successful lock by the same thread. >>>>> >>>>> There are no doubt other differences. (I don't know the ordering of gcc >>>>> cleanup functions when multiple variables go out of scope at the same >>>>> time.) And yes, extra effort is needed for a gcc cleanup function to >>>>> handle the details around freeing the mutex. >>>> >>>> Is it just details? Unlocking a mutex is not an action associated with >>>> the object's lifetime so gcc's cleanup mechanism seems to be the wrong >>>> thing. >>> >>> In C++, a perfectly good way to handle mutexes is with a "lock" class - >>> constructing the class object locks the mutex, and destructing it >>> unlocks it. gcc's cleanup is the closest you get to a destructor in C >>> (with gcc extensions). Note that the cleanup is associated with the >>> lifetime of a lock object on the mutex, not the mutex itself. >> >> Sure, but now I'm not sure what your point is here. Are you suggesting >> a gcc-C solution using a lock struct? I don't think that a bad way to >> do it, but it much more involved that the "defer" example that was >> posted. >> >>> (I'm not suggesting that using a cleanup function, or a defer, is >>> necessarily a good way to use a mutex in C.) >> >> My point is the gcc's "cleanup" does not seem to be quite up to the task >> in the way that the proposed "defer" is. You appeared to be saying that >> it was only some details that separated them, but that might be down to >> what constitutes a detail for you. > > I'm saying that gcc's cleanup can be used to implement the same things > that are shown in the "defer" example. Yes, I agree that using it for a > mutex is a more complicated, while using it for "free" is quite > straightforward. It looks like the "defer" idea has all sorts of > additional features not shown in this example, but for this kind of > common case I think you can use "cleanup" to get code that has the same > kind of source structure as the "defer" example. Agreed. It can be done. It's considerably more complicated*, but it can be done. * You need a new object with the right lifetime which must record the success or otherwise of the mtx_lock, and should have a pointer to the mutex to be unlocked. In addition, you need to define a function with the sole purpose doing the mtx_unlock. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-27 05:19 -0800 |
| Message-ID | <86lfdjwfn2.fsf@linuxsc.com> |
| In reply to | #157286 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Anton Shepelev <anton.txt@gmail.com> writes: > >> Thiago Adams: >> >>> https://gustedt.wordpress.com/2020/12/14/a-defer- >>> mechanism-for-c/ >> >> Is it the first consturction that, if accepted, will break >> C's literal interpretation of control-flow statements by >> introcuding a kind of action at a distance (and over time)? >> All the other control-flow statements are executed >> immediately... > > It's not entirely unlike atexit() and at_quick_exit(), but I agree its > a significant departure. I appreciate the effort that went into writing the proposal. But the proposal itself is a disaster.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-16 11:01 +0100 |
| Message-ID | <rrcltt$1jl$1@dont-email.me> |
| In reply to | #157279 |
> https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/ Better use C++, it has RAII which does what you try to initiate by this deferring manually.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-16 03:45 -0800 |
| Message-ID | <f52a7a27-b300-4333-bda1-23fc22c16bd2n@googlegroups.com> |
| In reply to | #157291 |
On Wednesday, December 16, 2020 at 7:01:48 AM UTC-3, Bonita Montero wrote: > > https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/ > > Better use C++, it has RAII which does what you try > to initiate by this deferring manually. C++ model and RAII is a kind of simplification because if you associate the cleanup function with the type this cannot be override by instance basis. With defer, having to inform the cleanup function all the time for the same type can be repetitive but is something more generic and and can be used in types that are not classes like FILE.
[toc] | [prev] | [next] | [standalone]
Page 6 of 15 — ← Prev page 1 … 4 5 [6] 7 8 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web