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
[email protected]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
