W1R2 SHM

[Torsten Scherer <itschere@TechFak.Uni-Bielefeld.DE>]

 First of all let me emphasize that W is no longer a MiNT-only project, so
either all add-ons come in a portable way, or they won't come. Since that
includes SHM the suggestion to write wrapper routines isn't really only a
suggestion, but in fact a requirement.

 Other than that, here're my comments to a couple of ideas from some of the
last mails about this (in no order):

[chris:]

> I've got the POSIX.4 spec here and I'm reading it (well, the bits about
> shared memory, since I'd like W to have that ASAP even if I don't do it
> :-)...  SysV shared memory is _similar_ to POSIX shared memory.

 I would be interested in *how* similar they are, can you point me to that
document?

> I'm going to have a go at implementing it so it can be added to
> MiNTlibs, but I don't think some things are going to be possible, or
> will need to be faked (like memory-mapping a file... has anyone got any
> brilliant ideas on how to implement that on a system with no MMU?).

 Well, the first way would be to have shmat() malloc() enough memory and
read the whole thing from the file - this will be fast (only a memcpy), but
will take quite some memory. Shmdt() is then merely a free(). And it
wouldn't require any particular hardware or additional support.

> If I find I'm too lazy to implement it, I'll post a summary to the MiNT
> list so someone else can get started.  :)

 Ah, come on! :)

[chris]

> > Also - I'm no longer familiar to
> > MiNT - you must somehow modify the request packet to state that shared
> > memory is to be used and how to get it.
>
> No problem, just send a new message to the server...  Instead of "draw
> this bitmap here", it'll say "get this bitmap from shared memory here,
> and draw it there"...

 It won't need a *new* message, just a bit more information. Currently the
(putblock-request-)paket looks like this:

typedef struct {
  short len;
  short type;
  short rwidth, rheight, x0, y0, width, height, handle, x1, y1;
  short res;
} PUTBLKREQP;

 'res' is there to pad the thing to a 4-byte-boundary. now change this to:

typedef struct {
  short len;
  short type;
  short rwidth, rheight, x0, y0, width, height, handle, x1, y1;
  short useShm;
  long key;
} PUTBLKREQP;

 and you've got all you need.

[chris:]

> Doesn't the server get SIGCHILD or something if one of its child programs
> dies?  Or at least a dead socket?  What does it do now if a program
> dies, doesn't it have things like fonts to clean up?

 It detects a dead socket. But once it's detected that, the block has already
been transfered and has already called shmdt() since each block of SHM will
only be used once - if you want to transfer the same bitmap n times you've
got to go through the SHM procedure n times. The only problem that remains
is what happens when the client is killed before the server has released
the segment - and manpages say in such a case the segment is kept until it
is released by the last program using it, in which case it is automatically
killed.

> Shared memory would of course work only locally although the server
> and apps can be run on different machines (have you tested this TeSche?).

 Assuming the machines you talk about are all big-endian ones that's ok.
I've noticed I had forgotten some conversions, but that'll be fixed in the
next version.

> For remote operation, we could be smart and cache the bitmaps in the
> server, either in /tmp or in memory (well, memory wouldn't be too smart
> for a 4M ST).

 There's no point in doing so. If you want to store bitmaps at the server
side to be even more faster you can use non-opened windows instead.

[Eero:]

> We have discussed about that...  It would probably be best to have a
> separate function (I assume that it would use those easy MiNT functions,
> not SYSV stuff) that sends the SHM file name to server, which would
> reply with an identifier recogniced by server.

 As I said above, it wouldn't need a seperate function, and I wouldn't like
to have a seperate function too. Why not make it totally transparent?

> Later putblocks would then just transfer the id and co-ordinates.

 I would say each put/getblock goes through the same procedure again. If
you want bitmaps to exist as shared memory segments for longer things will
get much more difficult and would really be much faster.

> Currently window, rect etc. structs on the server side are on a statically
> allocated area to avoid memory fragmentation.

 Currently that's no longer true. :)

ciao,
TeSche