Re: [Help-smalltalk] Datagram socket, async polling and image resume

[Holger Hans Peter Freyther]

On Thu, Aug 09, 2012 at 03:33:56PM +0200, Paolo Bonzini wrote:
> Do you want to keep the timeout behavior?  Or is it okay to just wait
> forever (I think so)?

I find the polling/timeout unwanted and to be honest I don't understand
why this is enabled for Datagrams and not with Streams.

> 
> > The bigger problem is with restoring an image where an async fileop is
> > made. There are two issues and I wonder about the best way to fix them.
> > The semaphoreOOP of the fileOp/polling queue will never be singalled, the
> > process sleeping in >>#ensureReadable will stay in this mode forever, the
> > usage count on the OOP will be wrong (no calls to _gst_unregister_oop).
> 
> I think the latter is not a problem, because the registry is not saved.

Hmm, I don't understand the save/restore too well but the entire oop
struct is saved to the image? This does include oop->usage. The entire
poll queue should make a gst_unregister_oop on the semaphore?

> So, in fact having the process in #ensureReadable forever is a feature,
> because it means that the references to stale file descriptors are not
> used.  You can fix the problem by going through your data structures at
> load time and ensuring that you are killing all references to the
> process objects.

okay, I will try it. But this complicates the code a bit for me. My standard
socket is doing is here[1]. For a 'normal' stop operation I close the socket
ensureReadable will go away, the process terminates, I signal a sempahore and
once both RX/TX are gone the stop method will return. For the image restore
the above will not work. I might be lucky with moving 'Forget things' a little
bit up and forcing a garbage collection after that. Does that make sense?


holger



[1] 
http://cgit.osmocom.org/cgit/smalltalk/osmo-st-network/tree/SocketBase.st?id=52a0026d329dae33eb07ebd436d03ed6f579143b