[Info-vax] SQLite port for OpenVMS (Re: Is there currently a functioning link for hobbyist licenses?)
Stephen Hoffman
seaohveh at hoffmanlabs.invalid
Thu Mar 12 19:45:43 EDT 2015
On 2015-03-12 23:14:29 +0000, Craig A. Berry said:
> I'm aware that the port of PostgreSQL is waiting on SSIO fixes. But my
> impression is that SSIO provides byte range locking via a new XFC
> interface that is able to do I/O with portions of a block rather than a
> whole block. Since SQLite uses byte range locking for shared access, it
> seemed a reasonable guess when people encountered trouble with locking
> in SQLite that SSIO might be the answer. Not proven, by any means, but a
> reasonable inference. Unless I've completely mixed up similar-sounding
> but unrelated things here.
I don't know enough about the innards of the C byte-range locking
implementation to answer that.
But I didn't think that the byte-range locking F_GETLK, F_SETLK, and
F_SETLKW bits and the SSIO bits were particularly connected.
> That said, I believe SQLite can do file-level locking (not sure if
> that's a fallback or explicitly requested option) and for a single
> application instance talking to its configuration data that's quite a
> reasonable way to do things. Why pay for concurrency if you don't need it?
>
> Anything I know about SSIO is from here:
>
> <http://de.openvms.org/TUD2012/opensource_and_unix_portability.pdf>
It'd be interesting to see some more technical details on SSIO as HP
has envisioned it. I can think of a pretty easy way to do shared
stream with rather less baggage than is included in that description,
which usually means I'm confused, or am missing some key detail from
the presentation or the SSIO technical specs or in application reality.
Unfortunately outside of the context of the CRTL, I'd need to intercept
and jacket the open, read, write and close I/O calls, or folks would
need to use variant calls when shared streams were needed, and either
of which is something that traditionally gets a little ugly.
If anybody has available a small — small! — hunk of C code that tries
to use shared streams and the C byte-range locking — some sort of a
reproducer — I'd be interested in seeing it, as part of trying to sort
this out.
--
Pure Personal Opinion | HoffmanLabs LLC
More information about the Info-vax
mailing list