Project

General

Profile

Bug #5194

Stream handle - type missing, not deletable

Added by Marian Edu over 5 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

History

#1 Updated by Marian Edu over 5 years ago

There are some issues with a stream handle, first it does not support type property - trying to access it eventually ends up with a stack overflow exception because invalidAttribute is calling getResourceType and since the attribute we're looking for is type to start with this goes in a nice loop :)

A simple test here oo/json/quirks/stream_type.p.

Trying to get around this by simply checking if the resource is a Stream works, however when we delete the handle in the final block HandleOps.delete sees this is not a system handle, nor a window nor it does implement 'deletable' (while it probably should) so it throws an error and again it (foolishly) believe would be nice to add the resource type to the error message and voila, we hit the loop again :)

#2 Updated by Greg Shah over 5 years ago

  • Assignee set to Constantin Asofiei

#3 Updated by Marian Edu over 5 years ago

As a side note when serializing JSON data to a stream the 4GL does not close the stream, however the data is being flushed at the end. The issue is the FileStream has a number of 'flush' methods but the inherited flush method does nothing beside notifying listeners if any. I did add an override for that method and call both flushData and flushBuffered before calling supper, if there is a better way please let me know.

Also, on Windows at least, the memory mapped stream is not correctly closed - once we write to a file we can't open it for reading anymore. Did mentioned that before but just to be sure, the workaround I use locally is to use memory mapped only from output stream (aka, write is true).

Also available in: Atom PDF