sockets 
Author Message
 sockets

Matthias,
Thanks for your rapid response.

Quote:
> 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!).

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



Sat, 20 Aug 2005 07:16:27 GMT  
 sockets

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

**WARNING: this message contains {*filter*} 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....

Quote:

>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 {*filter*} 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>
<blockquote type="cite"

  <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 ...

read more »



Sat, 20 Aug 2005 08:02:38 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. socket problems under windows: cannot load Socket.so under windows

2. SSL support for socket module for server sockets

3. Q: simple sockets, bind, and socket error 10048

4. NT Tcl socket vs. UNIX Tcl socket

5. Socket Help "Socket Newbie"

6. UDP sockets w/ db-sockets

7. Socket connection fails with socket already connected message

8. TCL and Socket TO Socket

9. old thread: SSL support for socket module for server sockets

10. SOCKET:SOCKET-STREAM missing?

11. VW/Sockets (detecting abnormally closed socket)

12. socket question:socket.error:(4,'Interrupted system call')

 

 
Powered by phpBB® Forum Software