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

[Paolo Bonzini]

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

> 
> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-smalltalk
>