Non-member submission from [Matthias Scheutz <mscheutz@cse.nd.edu>]
From: Matthias Scheutz <mscheutz@cse.nd.edu>
To: Roger Evans <Roger.Evans@itri.brighton.ac.uk>
cc: Aaron Sloman <A.Sloman@cs.bham.ac.uk>, pop-forum@cs.bham.ac.uk
Subject: Re: sockets
Dear Roger,
Thanks for your adult solution (this is really pop11 for the insider, a
league I'm not part of, but I can see the utility ;). I tried it, but
unfortunately it did not solve my problem; not because it did not set the
bit, but because the bit seems to be irrelevant to my problem as you
mentioned yourself (write errors still cause the mishap; furthermore, I've
discovered that I can also get read errors on the socket, so setting the
bit would not have solved the entire problem). Thanks anyway for the new
set of tricks I learned should I ever have the need to access low-level
datastructures.
All the best,
Matthias
> **WARNING: this message contains adult content - do not proceed if you
> are a programmer of delicate disposition** :-) :-)
>
> Matthias and Aaron,
>
> the other way to approach this problem is to patch up the flags in the
> device record. Aaron is of course correct when he points out the the !
> operator and various variables used are part of popc, and so not
> directly accessible at user level. However, like any self-respecting
> systems language, pop11, even user-pop11, can do more or less anything
> if it really wants to. And in this case 'if it really wants to' means
> using the fast_ non-checking subscriptors to access the raw data of your
> data objects. Take a deep breath, and here goes... (nb: all the numbers
> here are based on the win32 source, whcih si the only one I have. You
> should check against your own sources to see if the offsets are the same
> - though unless the io is *completely* different I can't see why they
> should not be...)
>
> The ! operator is just C's '->' in disguise, ie x!y means treat x as an
> address and offset y from it. So
>
> comm_sock!D_UNIT_N!UNT_FLAGS || M_UNT_IGNORE_WRITE_ERR ->
> comm_sock!D_UNIT_N!UNT_FLAGS;
>
> just means 'access the D_UNIT_N field of the device comm_sock, then
> access the UNT_FLAGS field of that, mask in the new flag and update back
> again. Searching system sources for D_UNIT_N finds it declared as a
> field of a device record, and its the second field after the key. What's
> more, in the absence of any other field type, its a 'full' field, ie a
> pointer to a normal complex poplog object (in fact it seems to be a
> string, being used to store raw data in a slightly lazy fashion). To
> access a full field of a data object, as a full poplog object, without
> the system complaining about the parent object's type, we use
> fast_subscrv (the non-checking vector subscriptor). Searching again for
> UNT_FLAGS we discover it is the 6'th DWORD field of the DEVUNIT_N struct
> (which is this record masquerading as a string). DWORDS are not full
> fields, so we can't use fast_subscrv to access them. But we can use a
> non-checking 32-bit integer subscriptor to get at it - we need to make
> one first though. Finally, we need to know that M_UNT_IGNORE_WRITE_ERR
> is actually 1 - again by searching the sources. . And then we can do this:
>
> defclass int32 :32; ;;; declare a class of 32-bit
> integers (to give us the fast_subscriptor)
>
> fast_subcrint32(6, fast_subscrv(2,comm_sock)) || 1 ->
> fast_subscrint32(6, fast_subscrv(2, comm_sock));
>
> And hopefully that will work. (Sadly, I don't have time to test it right
> now - do let me know :-) ).
>
> Note, however, that M_UNT_IGNORE_WRITE_ERR's real role seems to be to
> block multiple write errors, so at the end of the day I don't know
> whether this patch will actually behave itself - all I've done here is
> show you how to rewrite the piece of code that was giving you grief.
>
> Roger
>
> PS: I'm sure you can do it with 'exacc' too, but only after spending
> several hours on the exacc documentation to remember how....
>
> Aaron Sloman wrote:
> ....
|