[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Holger Hans Peter Freyther
Subject: Re: [Help-smalltalk] Datagram socket, async polling and image resume
Date: Thu, 9 Aug 2012 21:38:14 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]