Forwarded (Matthias Scheutz) Re: sockets 
Author Message
 Forwarded (Matthias Scheutz) Re: sockets





Subject: Re: sockets

Aaron,

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

That one worked (I had to rewrite my code a bit so as to exit to a common
ancestor of the procedure I was calling, and I had to add mechanisms for
read errors as well, which I had not gotten in the past--this is why
setting the bit for ignoring write errors as I had in mind originally was
not going to work anyway).  Thank you very much for the hint

Best,
Matthias

Matthias Scheutz
---------------------------------------------------------------
Assistant Professor                 http://www.*-*-*.com/ ~mscheutz/
Dept. of Computer Science and Engineering, 351 Fitzpatrick Hall
University of Notre Dame                   Notre Dame, IN 46556
USA                                    Phone: +1 (574) 631-0353



Sun, 21 Aug 2005 21:27:33 GMT  
 Forwarded (Matthias Scheutz) Re: sockets




Subject: Re: sockets

Dear Roger,

Thanks for your {*filter*} 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

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


> ....



Mon, 22 Aug 2005 01:40:52 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Forwarded (Matthias Scheutz) Re: Sockets problem

2. forwarded message suppressing write errors on sockets

3. Matthias Radestock

4. Please reply to me: homann@charlie.nymphe.isar.muc.de (Matthias Homann)

5. Whereabouts of Dr. Matthias Otto, Frieberg, Germany.

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

7. SSL support for socket module for server sockets

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

9. NT Tcl socket vs. UNIX Tcl socket

10. Socket Help "Socket Newbie"

11. UDP sockets w/ db-sockets

12. Socket connection fails with socket already connected message

 

 
Powered by phpBB® Forum Software