[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Mar 4 00:02:38 2003 
Subject:Re: sockets 
From:Roger . Evans 
Volume-ID:1030304.01 


--------------030701000300080907000209
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

**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:

>Matthias,
>Thanks for your rapid response.
>
>  
>
>>Thanks for your message and for posting it.  The quick version, however,
>>did not work for me (I had tried something like that at some earlier
>>point, but to be sure I tried it again), I got the following error:
>>
>>;;; MISHAP - DECLARING PROTECTED IDENTIFIER AS DYNAMIC LOCAL
>>;;; INVOLVING:  mishap
>>    
>>
>
>Sorry: that was me being forgetful. The system procedure mishap is not
>user-defineable. Rather, it calls a procedure prmishap, with the same
>arguments, which is user-definable.
>
>The default value of prmishap is usually sysprmishap, which merely
>prints the standard error message.
>
>If prmishap exits normally then mishap aborts the current procedure,
>and interrupts. But that is prevented if prmishap uses chainto, or
>exitto, etc.
>
>(That's how things used to be. There is now a more general mechanism
>described in REF exception, on top of which all that is now built, but I
>have never studied or usd it!).
>
>  
>
>>Maybe I need to set a compile option to get passed it?  In this case, if I
>>could get away with redefining the mishap function, I'd be more than happy
>>(although I would prefer a cleaner solution that would allow me to set the
>>appropriate bit).  Anyway, I'll keep trying (once this problem is
>>resolved, I think I should have a complete "grid computing" server for
>>simworld).
>>    
>>
>
>Just try redefining prmishap. You can, for exmaple use that trick to
>alter the behaviour of "+" so that "one" + "two" evaluates to "three"
>instead of producing a mishap!
>
>Aaron
>
>  
>


--------------030701000300080907000209
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
**WARNING: this message contains adult content - do not proceed if you are
a programmer of delicate disposition** &nbsp;:-) :-)<br>
<br>
Matthias and Aaron,<br>
<br>
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...)<br>
<br>
The ! operator is just C's '-&gt;' in disguise, ie x!y means treat x as an
address and offset y from it. So<br>
<blockquote><tt>comm_sock!D_UNIT_N!UNT_FLAGS || M_UNT_IGNORE_WRITE_ERR -&gt;<br>
&nbsp; &nbsp;&nbsp; comm_sock!D_UNIT_N!UNT_FLAGS;</tt></blockquote>
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:<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; defclass int32 :32;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ;;; declare a class of 32-bit integers
(to give us the fast_subscriptor)<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; fast_subcrint32(6, fast_subscrv(2,comm_sock)) || 1 -&gt; fast_subscrint32(6,
fast_subscrv(2, comm_sock));<br>
<br>
And hopefully that will work. (Sadly, I don't have time to test it right
now - do let me know :-) ).<br>
<br>
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.<br>
<br>
Roger<br>
<br>
PS: I'm sure you can do it with 'exacc' too, but only after spending several
hours on the exacc documentation to remember how....<br>
<br>
<br>
<br>
Aaron Sloman wrote:<br>
<blockquote type="cite"
 cite="mid200303032316.h23NGFI3027280@acws-0051.cs.bham.ac.uk">
  <pre wrap="">Matthias,
Thanks for your rapid response.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Thanks for your message and for posting it.  The quick version, however,
did not work for me (I had tried something like that at some earlier
point, but to be sure I tried it again), I got the following error:

;;; MISHAP - DECLARING PROTECTED IDENTIFIER AS DYNAMIC LOCAL
;;; INVOLVING:  mishap
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Sorry: that was me being forgetful. The system procedure mishap is not
user-defineable. Rather, it calls a procedure prmishap, with the same
arguments, which is user-definable.

The default value of prmishap is usually sysprmishap, which merely
prints the standard error message.

If prmishap exits normally then mishap aborts the current procedure,
and interrupts. But that is prevented if prmishap uses chainto, or
exitto, etc.

(That's how things used to be. There is now a more general mechanism
described in REF exception, on top of which all that is now built, but I
have never studied or usd it!).

  </pre>
  <blockquote type="cite">
    <pre wrap="">Maybe I need to set a compile option to get passed it?  In this case, if I
could get away with redefining the mishap function, I'd be more than happy
(although I would prefer a cleaner solution that would allow me to set the
appropriate bit).  Anyway, I'll keep trying (once this problem is
resolved, I think I should have a complete "grid computing" server for
simworld).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Just try redefining prmishap. You can, for exmaple use that trick to
alter the behaviour of "+" so that "one" + "two" evaluates to "three"
instead of producing a mishap!

Aaron

  </pre>
</blockquote>
<br>
</body>
</html>

--------------030701000300080907000209--