Socket question
Locked
 
|
In a clean VWNC image (I am using VW 7.4.1) I find that I get a bonus
instance of SocketAccessor when setting up a socket. I'm running the image on Debian stable (sarge). Try this one step at a time in a workspace in a completely clean image: SocketAccessor allInstances size. "I get zero which is what I would expect" newAccessor := SocketAccessor newTCP. SocketAccessor allInstances size. "Now I get 2 !?" SocketAccessor allInstances select: [:s| s isActive]. "Both 'active'!" newAccessor isActive. "true, as expected" newAccessor close. newAccessor isActive. "false, as expected' SocketAccessor allInstances select: [:s| s isActive]. "The bonus instance still 'active'" SocketAccessor allInstances do: [:s | s close] . SocketAccessor allInstances select: [:s| s isActive]. "zero active, phew". Is this supposed to happen? If so, could someone please explain this for me :-] Many thanks, Bruce -- Make the most of your skills - with OpenSkills http://www.openskills.org/ |
|
|
Bruce Badger wrote:
> In a clean VWNC image (I am using VW 7.4.1) I find that I get a bonus > instance of SocketAccessor when setting up a socket. I'm running the > image on Debian stable (sarge). Ditto for windows and other classes that register an OS handle I suppose. I didn't research your example but I guess you are looking at the #executor alongside your your 'real' instance. R - > > Try this one step at a time in a workspace in a completely clean image: > > SocketAccessor allInstances size. "I get zero which is what I would > expect" > newAccessor := SocketAccessor newTCP. > SocketAccessor allInstances size. "Now I get 2 !?" > SocketAccessor allInstances select: [:s| s isActive]. "Both 'active'!" > newAccessor isActive. "true, as expected" > newAccessor close. > newAccessor isActive. "false, as expected' > SocketAccessor allInstances select: [:s| s isActive]. "The bonus > instance still 'active'" > SocketAccessor allInstances do: [:s | s close] . > SocketAccessor allInstances select: [:s| s isActive]. "zero active, > phew". > > Is this supposed to happen? If so, could someone please explain this > for me :-] > > Many thanks, > Bruce |
|
|
In reply to this post by Bruce Badger
This second one probably is the executor that finalizes the "real" instance of the socket. Some classes like ExternalDatabase classes use that mechanism, too. Thomas > -----Original Message----- > From: Bruce Badger [mailto:[hidden email]] > Sent: Tuesday, March 20, 2007 2:11 PM > To: vwnc-list > Subject: Socket question > > In a clean VWNC image (I am using VW 7.4.1) I find that I get a bonus > instance of SocketAccessor when setting up a socket. I'm running the > image on Debian stable (sarge). > > Try this one step at a time in a workspace in a completely > clean image: > > SocketAccessor allInstances size. "I get zero which is what I > would expect" > newAccessor := SocketAccessor newTCP. > SocketAccessor allInstances size. "Now I get 2 !?" > SocketAccessor allInstances select: [:s| s isActive]. "Both > 'active'!" > newAccessor isActive. "true, as expected" > newAccessor close. > newAccessor isActive. "false, as expected' > SocketAccessor allInstances select: [:s| s isActive]. "The bonus > instance still 'active'" > SocketAccessor allInstances do: [:s | s close] . > SocketAccessor allInstances select: [:s| s isActive]. "zero > active, phew". > > Is this supposed to happen? If so, could someone please > explain this for me :-] > > Many thanks, > Bruce > -- > Make the most of your skills - with OpenSkills > http://www.openskills.org/ > > |
|
|
In reply to this post by Reinout Heeck-2
Reinout,
On 20/03/07, Reinout Heeck <[hidden email]> wrote: > Ditto for windows and other classes that register an OS handle I suppose. I only have Linux here, so I don't know :-/ > I didn't research your example but I guess you are looking at the > #executor alongside your your 'real' instance. Ooooh, part of the reaping thing? OK - though I can't see the code that makes that happen for SocketAccessor. Still, it's odd that such a socket should be active. Even more so after I close the real one. I came across this because I was getting the 100% CPU problem we have seen with sockets in VW ... but all the sockets I had opened had been closed and I could not figure out where these stray active sockets had come from. Confusing. Thanks for the response Reinout. All the best, Bruce -- Make the most of your skills - with OpenSkills http://www.openskills.org/ |
|
|
Bruce Badger wrote:
> Reinout, > > On 20/03/07, Reinout Heeck <[hidden email]> wrote: >> Ditto for windows and other classes that register an OS handle I >> suppose. > > I only have Linux here, so I don't know :-/ Same. > >> I didn't research your example but I guess you are looking at the >> #executor alongside your your 'real' instance. > > Ooooh, part of the reaping thing? OK - though I can't see the code > that makes that happen for SocketAccessor. Still, it's odd that such > a socket should be active. Even more so after I close the real one. SocketAccessor is subclass of OSHandle. OSHandle defines class inst var 'registry' which contains a HandleRegistry (see #register:) HandleRegistry is subclass of WeakDictionary WeakDictionary>>unlockedAt:put: sends #executor to the value #executor is implemented as ^self shallowCopy on Object. This should also explain why half of the SocketAccessor instances stay 'active' when all sockets are closed: their state was just a copy of an active SocketAccessor. If the original goes inactive there is no code (nor need) to synchronize the copy. For cleanliness the executor could have all fields nilled out except for its handle - since it is not built that way you got confused... R - |
|
|
On 20/03/07, Reinout Heeck <[hidden email]> wrote:
> For cleanliness the executor could have all fields nilled out except for > its handle - since it is not built that way you got confused... It's also a worry that these copies can consume system resources, as I observed. I did get confused, but your explanation fixed that :-) Thanks again, Bruce -- Make the most of your skills - with OpenSkills http://www.openskills.org/ |
|
|
In reply to this post by Reinout Heeck-2
On Mar 20, 2007, at 7:36, Reinout Heeck wrote:
This is a tangent... I have always found this mechanism difficult to work with. It's confusing to say the least. But it's what was doable at the time. Usually it's just a black box and I don't have to deal with it. When I did the Cairo stuff, I found myself needing the same type of mechanism. I tried initially to use the OSHandle/Registry stuff. It ended up caving under it's own pressure. Luckily, now days we have this #ephemeron object type. I was able to leverage this new behavior by wrapping my handle objects with an #ephemeron type object rather than doing a shallowCopy and all that. I used the API provided by the Weaklings package to basically do something like: self knownHandles at: anObject handle put: (anObject withLastRites: [:obj | self forgetHandle: obj handle. obj destroy]) The upshot is that there is no need for a "ghost" variant of the object. -- Travis Griggs Objologist "I choose. Therefore, I Am" |
|
|
On 20/03/07, Travis Griggs <[hidden email]> wrote:
> Luckily, now days we have this #ephemeron object type. ... > The upshot is that there is no need for a "ghost" variant of the object. Does this mean there can be an AR to address this in the case of SocketAccessor? :-) -- Make the most of your skills - with OpenSkills http://www.openskills.org/ |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |