Hi,
Glad to know the problem has been identified. But the workaround
is not very suitable for my situation, from the data source has no
idea about whether the queue is filling up. We were expecting to make
flow control based on used memory. But we cannot get detailed memory
used by each write
To chime in from the Go side, all Go memory is typically
automatically zero-ed out anyways, so by default the Go implementation will
also fit this invariant with all of the buffers being zero-ed out.
On Mon, Jul 31, 2023 at 5:18 PM Pedro Eugenio Rocha Pedreira
wrote:
> > My only major comment
> My only major comment so far is that views for null slots I think should be
> well defined, that is they shouldn't reference buffers or data that
> doesn't exist. This is very important for the Rust implementation to be
> able to provide efficient safe APIs.
Quickly chiming in here again: FWIW,
Thanks. This is a very helpful reproduction.
I was able to reproduce and diagnose the problem. There is a bug on our
end and I have filed [1] to address it. There are a lot more details in
the ticket if you are interested. In the meantime, the only workaround I
can think of is probably to
+1 (binding) -- verified on x86_64 mac
On Sun, Jul 30, 2023 at 12:33 PM Raphael Taylor-Davies
wrote:
> Hi,
>
> I would like to propose a release of Apache Arrow Rust Implementation,
> version 45.0.0.
>
> This release candidate is based on commit:
> 16744e5ac08d9ead6c51ff6e08d8b91e87460c52 [1]
>
Hi All,
Having played around with various alternatives, I think we should move
ahead with this proposal. I think Utf8View and BinaryView would be a
valuable addition to the arrow specification, and would address many of
the current pain points encountered when dealing with large string
