- More precision about my new inventions of scalable algorithms.. - 3 Updates
- New Python implementation - 3 Updates
- #include'ing .c files considered harmful? - 1 Update
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 24 06:20PM +0100 > It does depend on the implementation if frequent reads can starve out > writers. But if this happens is a matter of the lock-behaviour. |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 24 06:22PM +0100 > is to have OS support to kill those clients and have it unlock the locks > it held on to. (It could not kill but just deny further access depending > on the resource). We're talking about locks which protect shared datastructures. In this case it would be stupid to kill a process or thread holding such a lock. |
| Richard Damon <Richard@Damon-Family.org>: Feb 24 01:28PM -0500 On 2/24/21 12:22 PM, Bonita Montero wrote: >> on the resource). > We're talking about locks which protect shared datastructures. In this > case it would be stupid to kill a process or thread holding such a lock. A lock that works with the OS to so the OS knows what locks the process holds can kill a 'bad' process and force the release of the lock. The only way to handle 'bad' processes, is for there to be some mechanism to deny that process access to the resource that it has taken the lock on, so it can be given to someone else. That capability is typically reserved to the OS. Yes, if you abort a process in the middle of its operation, you may need to do some 'cleanup' on the resource, but if the process isn't releasing the resource in the required time, can you really trust that it is doing its job right? |
| mickspud@potatofield.co.uk: Feb 24 09:23AM On Tue, 23 Feb 2021 17:34:00 GMT >>if something goes wrong. Its called a Kernel panic or blue screen in Windows. >Windows is hardly an exemplar of operating system design. I've been >writing operating systems for four decades, and I stand by my assertion. I was thinking of *nix mainly, my Windows dev experience is limited. >It is quite possible for applications to be quite resiliant, when using >real operating systems. Tandem non-stop comes to mind, and they're still >chugging away (HPE). Tandem was a specialist OS and will probably diverge from common OS's in how threads and processes are demarcated. Anyway, the non-stop part is referring to the OS maintaining the processes if some hardware goes down, not keeping them alive if the process itself crashes. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 24 05:16PM +0100 On 11.02.2021 13:29, Mr Flibble wrote: > I am starting work on creating a new Python implementation from scratch [snip] Possibly relevant: the Julia programming language, e.g. see https://www.nature.com/articles/d41586-019-02310-3 - Alf |
| mickspud@potatofield.co.uk: Feb 24 05:01PM On Wed, 24 Feb 2021 17:16:59 +0100 >On 11.02.2021 13:29, Mr Flibble wrote: >> I am starting work on creating a new Python implementation from scratch >[snip] I missed that recent bit of bullshittery from the groups resident comedian. There needs to be a new category beyond vapourware for his software, perhaps Heisenbergware to go along with Heisenbugs - when you look for it it magically vanishes. |
| antispam@math.uni.wroc.pl: Feb 24 01:27AM > multiple times. We don't have to scan the cpu.c copyright header > multiple times, and not do those #include's twice that are not affected > by _GEN_ARCH. Well, if you consider self inclusion as bad (or maybe very complicated) thing, then as you showd one can do this without self inclusion. I do not know why the authors prefered self inclusion. But they have real need to compile the same code in few slightly different contexts. And self inclusion solves this need. I find the code quite readible and it works fine. I can speculate that they used self inclusion because this keeps related code in single file, but I do not know if this is real reason. Anyway, if you look at this in unbiased way, then alternatives are really not simpler. -- Waldek Hebisch |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment