Re: [PATCH] [IOS] Avoid spurious EOF when writing partial bytes

[Jose E. Marchesi]

> I feel that there are a few different options here;
>
> a) Don't support write-only IOS at all, since poke may need to read.
>
>    This is consistent, but boring :)

Booooo! :D

> b) Support write-only IOS, with the assumption that the backing store
>    does not change out from under poke, in which case it is safe to
>    cache just-written data in poke, thus poke knows what it "would
>    have" read.
>
>    This is consistent... up until the user encounters an IOS with
>    other writers and principle of least surprise is violated.

But what happens if the IO space already contains some bytes that are
not zero?

> c) [your proposal] Support write-only IOS, but anything that would
>    need to read fails with an exception.
>
>    This is something of a consistency breakage; everywhere else, poke
>    appears to ignore the common limitations of byte-level writing,
>    etc.

Agreed.  But on the other hand, it is documented and assumed that IO
devices are byte oriented (unlike the IOS abstraction built on top of
it.) so this need to read completing bytes shoulnd't be much of a
surprise.

>    Using an EOF exception would be quite confusing for the user as
>    well; if this is implemented, please use a more accurate exception
>    (maybe a new one needs to be added)

Yes, EOF is confusing.

I think we really want to introduce an E_perm exception, and raise it in
every peek* PVM instruction if the IO space doesn't support read.  Then
a dump of a non-readable IO space, for example, would raise the
exception instead of showing us an "empty" IO space.

>    With this idea, if the user wishes to use a write-only IOS in a
>    fully general manner, they must use another IOS as temporary
>    storage.

Right.  That is easy to do with .mem IOS.  If we go with this option I
will write a tutorial-like section in the manual describing how to
operate on write-only IO spaces.

Let's also keep in mind that write-only IO spaces will be very rare.

> d) Support write-only IOS, with some explicit flag/state enabling
>    caching as per option B.
>
>    I believe this would provide a level of consistency for poke users,
>    while maintaining least-surprise. If the user is using write-only
>    IOS, which is something of an advanced feature, they can check the
>    manual and/or the exception message to discover the caching feature :)

As with b), I can't see how caching fixes this problem?  poke has no
control (nor knowledge if it is write-only) of the previous contents of
the IO space, so it cant' use the right completing bytes.

> e) Implement transactional I/O in poke.
>
>    This is the "fun" option, which may be over-ambitious. Write-only
>    IOS and read-write IOS which may have other concurrent writers
>    present a common challenge. Thus, it may be interesting to
>    introduce a flag/state where all write operations are queued up in
>    an implicit memory IOS (or an explicit arbitrary IOS?) and then
>    committed or rolled back by the user.

That is also in the TODO, i.e. in etc/poke.rec:

Summary: Support IO transactions
Component: IO
Kind: ENH
Priority: 2
Description:
+ (poke) ... poke something ...
+ (poke*) ... poke something more ...
+ (poke*) .changes
+ - 000043: 0034 aabb
+ + 000043: ffff ffff
+ (poke*) .commit
+ Written 4 #B to IO foo.o
+
+ (poke*) .rollback

All in all, I would still pick c).