Datagram socket, async polling and image resume

Hi Paolo,

this is is with the stable 3.2. Yesterday I noticed that DatagramSocket
will use some form of polling inside the >>#next selector. This is not
true for other sockets/filedescriptors and a bit annoying when closing
down a socket. My current workaround is to use the ensureReadable (which
will use async polling fileop) and then use next. The second part is
that >>#next and >>#ensureReadable do not generate a EoF in case the
socket is closed.

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 wonder how to fix the later issue. I think it should happen somehow
in the fixup_object method of save.c. E.g. in pseudo code

fixup: semaphoreOOp
 polling_queue includes: semaphoreOOp
        ifTrue: [
                OBJECT(semaphoreOOP) signal.
                unregisterOOP: semaphoreOOP.]

I am not sure if the process will automatically run after the above
manipulation.

what do you think?

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 09/08/2012 11:46, Holger Hans Peter Freyther ha scritto:
> Hi Paolo,
>
> this is is with the stable 3.2. Yesterday I noticed that DatagramSocket
> will use some form of polling inside the >>#next selector. This is not
> true for other sockets/filedescriptors and a bit annoying when closing
> down a socket. My current workaround is to use the ensureReadable (which
> will use async polling fileop) and then use next.

Do you want to keep the timeout behavior?  Or is it okay to just wait
forever (I think so)?

> 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.

If nothing is holding a reference to the process except the semaphore,
on restart both objects will be dead: the process is the only object
that refers to the semaphore (from myList) and vice versa (from firstLink).

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.

Paolo



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

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

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Thu, Aug 09, 2012 at 09:38:14PM +0200, Holger Hans Peter Freyther wrote:
> 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?

I did the modification, the process is garbage collected and the ensure: []
is never called. My second option would be finalizers? My basic concern is
that at no time I want to have two handlers running (this is why I use a
semaphore).

any ideas?
        holger


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk