[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?
holger
[1]
http://cgit.osmocom.org/cgit/smalltalk/osmo-st-network/tree/SocketBase.st?id=52a0026d329dae33eb07ebd436d03ed6f579143b