9front - general discussion about 9front
 help / color / mirror / Atom feed
From: ori@eigenstate.org
To: 9front@9front.org
Subject: Re: [9front] Thoughts on Wayland?
Date: Sun, 04 Aug 2024 18:57:16 -0400	[thread overview]
Message-ID: <FC4CC590407F5F9C3A0B5FF33C017FBC@eigenstate.org> (raw)
In-Reply-To: <E09824C9-CA66-4147-9588-F04C6FD4E1BC@icloud.com>

Quoth David Leimbach <leimy2k@icloud.com>:
> 
> Sent from my iPhone
> 
> > On Aug 4, 2024, at 3:28 PM, ori@eigenstate.org wrote:
> > 
> > Quoth David Leimbach <leimy2k@icloud.com>:
> >> 
> >>> 
> >>>> 
> >>>> While it's theoretically possible to do mmap over 9p, it's not going to
> >>>> be a good experience.
> >> 
> >> Is it substantially worse than mmap’ing over NFS? I can imagine a lot of panic or deadlock cases but…. Yeah that’s true for NFS also. At least a core dump.
> >> 
> > 
> > I'm not familiar enough with the internals of the NFS
> > protocol to say for sure.
> > 
> > However, dont' just consider deadlock, consider coherence.
> > What happens if you put a mutex into shm, and two machines
> > try to lock it at the same time?
> > 
> > How do you avoid turning every single memory access into
> > a network round trip without some sort of sideband protocol?
> > 
> > What happens if a laptop participating in that coherence
> > mechanism gets its lid closed and hibernates for an hour or
> > three, and then comes back?
> 
> 
> It’s a nasty game of timeouts and hangups… like everything in distributed systems. 
> 

ah, except in a distributed system, locks are provably broken;
they can't even work in theory.

Imagine two cases:
1) a machine takes a lock, pauses for an arbitrary amount
   of time, and then tries to proceed with its critical
   section, assuming that nobody has mutated its state

2) a macine takes a lock, and then dies permanently, never
   to return.

you can do one of two things here: you can either time out
the lock, or hold it forever.

in case 1, if you hold it forever, the system is correct.
If you time it out, you've just done critical work outside
a critical section and corrupted data.

in case 2, if you hold it forever, you have a deadlock that
can't be recovered from; the machine is never coming back.

you need a correct distributed system to obey wait-free like
properties.

sofware needs to be designed from the ground up to be aware
of the complexity of distributed systems; if you try to take
a system that was designed to run on a single failure domain
and make it distributed by layering over something like mmap,
either things get very complex, or they get very broken; that
is not an exclusive or.


  reply	other threads:[~2024-08-04 23:01 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-04 19:26 Willow Liquorice
2024-08-04 19:44 ` Stuart Morrow
2024-08-04 19:49   ` Willow Liquorice
2024-08-04 19:54   ` Eli Cohen
2024-08-04 19:59     ` Eli Cohen
2024-08-04 20:04       ` Eli Cohen
2024-08-04 20:05         ` Eli Cohen
2024-08-04 20:09         ` Willow Liquorice
2024-08-04 20:29           ` Eli Cohen
2024-08-04 21:23           ` ori
2024-08-04 21:43             ` ori
2024-08-04 22:00               ` David Leimbach
2024-08-04 22:22                 ` ori
2024-08-04 22:42                   ` David Leimbach
2024-08-04 22:57                     ` ori [this message]
2024-08-04 21:10       ` Willow Liquorice
2024-08-04 21:24         ` ori
2024-08-04 21:25         ` Eli Cohen
2024-08-05  8:13         ` Willow Liquorice
2024-08-05  8:29           ` ori
2024-08-05  8:52             ` sirjofri
2024-08-05  8:57               ` Noam Preil
2024-08-05  9:12                 ` sirjofri
2024-08-05 11:51                 ` hiro
2024-08-05  9:03               ` Willow Liquorice
2024-08-05 11:05               ` Shawn Rutledge
2024-08-05 12:01                 ` hiro
2024-08-05 12:26                 ` sirjofri
2024-08-05 11:15               ` David Arnold
2024-08-05 11:47               ` hiro
2024-08-05 12:35                 ` sirjofri
2024-08-04 20:01     ` Willow Liquorice
2024-08-04 21:23       ` sirjofri
2024-08-04 20:08     ` mkf9
2024-08-04 20:35       ` Willow Liquorice
2024-08-04 20:32 ` Pavel Renev
2024-08-04 21:31 ` ori
2024-08-05  6:09   ` Noam Preil
2024-08-05  8:02     ` hiro
2024-08-05 11:51       ` Shawn Rutledge
2024-08-06 16:37         ` hiro
2024-08-06 17:57           ` sirjofri
2024-08-07  9:27           ` Steve simon
2024-08-07 11:47             ` hiro
2024-08-05 12:54   ` Willow Liquorice
2024-08-05 13:13     ` [9front] Fortune worthy Steve simon
2024-08-05 20:06     ` [9front] Thoughts on Wayland? Jon Sharp
2024-08-06  0:07       ` Eli Cohen
2024-08-06  0:09         ` Eli Cohen
2024-08-06  1:57           ` Michael Misch
2024-08-06 13:01         ` Emil Tomczyk
2024-08-04 22:27 ` Dave MacFarlane
2024-08-05  6:10   ` Noam Preil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FC4CC590407F5F9C3A0B5FF33C017FBC@eigenstate.org \
    --to=ori@eigenstate.org \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).