hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
<satacker[m]>
The value of sends_stopped for the default sender traits of types that are generally awaitable was changed from false to true to acknowledge the fact that some coroutine types are generally awaitable and may implement the unhandled_stopped() protocol in their promise types.
<Yorlik>
Probably some variation of a span could do the trick.
<john98zakaria[m]>
s/I remember somewhere that's possible to get the actual vector from the buffer/I remember somewhere that's possible to get the actual vector from the server on which the locality lives /
<Yorlik>
Yes - I can use a vector like a buffer if I guarantee, that it's not reallocating/moving data while using it as such.
<Yorlik>
Interfacing C code sometimes sucks :(
<john98zakaria[m]>
You could add a shared lock to the implementation, then maybe it will then do the trick
<john98zakaria[m]>
I am adding one right now as I am trying to use it as a channel that accepts only one message and waits to get fetched
<Yorlik>
Instead of implementing some special vector I'll probably just use a span, maybe inside a struct with some additional convenience code, e.g. for overtaking ownership of the data.
<john98zakaria[m]>
Is it possible to create a server component first, then create the client for it ?
<Yorlik>
john98zakaria[m] I believe there is no way for a vector to take ownership of a C array. Closest I can get probably is creating a copy as efficiently as possible, e.g. using memcpy if I have PODs in the array. It's a can of worms. Span is nice top get a view on the areaand especially gsl::span still has bounds checking, but that's as far as it gets.
<Yorlik>
If the C array is new'ed I could wrap the pointer to it into a unique_ptr ( possibly with a custom deleter) and store it together with the span in a struct.
<Yorlik>
So when the struct gets deleted, so does the C Array via the unique_ptr.
<Yorlik>
hkaiser: I'm facing the challenge of interfacing a preexisting blob(start, size) but can't use a span (could use gsl::span though. I wonder what's the the bast way to do that.
<Yorlik>
Unfortunately I need to go now - I have an external appointment.
<Yorlik>
I'll be back later.
* Yorlik
waves and fades.
<hkaiser>
satacker[m]: need to look closer
<hkaiser>
satacker[m]: why does this make it fail?
<satacker[m]>
completion_signatures_of_t<S, E>::sends_stopped shall have the same value
<satacker[m]>
// as completion_signatures_of_t<S, no_env>::sends_stopped.
<satacker[m]>
* ```
<satacker[m]>
// completion_signatures_of_t<S, E>::sends_stopped shall have the same value
<satacker[m]>
// as completion_signatures_of_t<S, no_env>::sends_stopped.
<satacker[m]>
```
<hkaiser>
ok
<hkaiser>
so this isn't the case, then?
<hkaiser>
don't we have a test verifying this?
<satacker[m]>
This is the case
<satacker[m]>
My test failed as a consequence of this
<hkaiser>
hmmm, now I'm confused
<hkaiser>
if completion_signatures_of_t<S, E>::sends_stopped has the same value as completion_signatures_of_t<S, no_env>::sends_stopped, then what is the issue?
<satacker[m]>
1. What is the use of `hpx::execution::experimental::env_of_t<receiver>` ? considering above case
<satacker[m]>
2. What should we change the `sender_1` implementation from the test ? We need to pass the static_assert
<hkaiser>
the statement above just means that the env a receiver is used in should not change it's completion signatures
<hkaiser>
sorry s/receiver/sender/
<satacker[m]>
But we will never know this because it always returns `no_env` signature?
<hkaiser>
what 'returns the no_env signature'?
<satacker[m]>
`sends_stopped` has the same value as ` completion_signatures_of_t<S, no_env>::sends_stopped` anyways so what difference will it make
<satacker[m]>
Irrespective of the type `E` in `completion_signatures_of_t<S, E>::sends_stopped`
<hkaiser>
yes
<hkaiser>
sorry, I still not understand your question
<satacker[m]>
Why do we need `<S,E>` when E is always `no_env` ?
<hkaiser>
only for send_stopped
<hkaiser>
the other signatures may change, I believe
<satacker[m]>
Okay, that was very silly of me then, thanks for answering
<satacker[m]>
So about the 2nd question?
<hkaiser>
could repeat that?
<satacker[m]>
What should we change the sender_1 implementation from the test ? We need to pass the static_assert
<hkaiser>
satacker[m]: I do not understand why the test needs to be changed, are you saying, that our test is flawed and we need to fix it?
<hkaiser>
(which is a perfectly valid possibility, btw) ;-)
<satacker[m]>
I don't know about it being flawed but `is_sender_of` will need sends_stopped to be true to pass ?
<hkaiser>
probably
<satacker[m]>
Also is one definition rule related to this
<satacker[m]>
```
<satacker[m]>
If completion_signatures_of_t<S, env_of_t<R>>::sends_stopped is well formed and false, such a sender S shall not odr-use execution::set_stopped(r).
<satacker[m]>
```
<hkaiser>
I don't have the full picture in my head
<hkaiser>
it says that if a sender says it doesn't call set_stopped, then it shouldn't attempt to do so
<satacker[m]>
but receiver calls it, does it affect?
<satacker[m]>
I guess not
<hkaiser>
a receiver never calls set_stopped, only senders do
<hkaiser>
a receiver may expose a set_stopped, but the sender may not support calling it
<hkaiser>
but if a sender says it may call sent_stopped, then the receiver needs to expose (and support) it
<satacker[m]>
Okay, thanks, isn't this the same case as now?
<satacker[m]>
The sender_1 sends_stopped is false which says that it doesn't support, yet the receiver exposes
<hkaiser>
that is ok
<hkaiser>
is_receiver_of needs to verify that if the sender supports set_stopped the receiver actually exposes it
<satacker[m]>
Yes, I understand this, thanks
<satacker[m]>
Let me think over what needs to be changed
<Yorlik>
hkaiser:yt?
<hkaiser>
Yorlik: here now
<hkaiser>
Yorlik: I didn't understand your question, could you elaborate, please?
<Yorlik>
Hello!
<Yorlik>
OK
<Yorlik>
I am working on our networking library, ironing out some wrinkles.
<Yorlik>
We are interfacing a low level library, written in a very C stylish C++-
<Yorlik>
So we get raw pointers or raw pointers and sizes for buffers etc.
<hkaiser>
ok
<Yorlik>
I want to wrap all that Cish stuff into safe types.
<hkaiser>
can you use std::span?
<Yorlik>
One particular issue is the *start, size combo
<Yorlik>
We are on C++17 and cannot upgrade becaUSE OF uNREAL ENGINE
<Yorlik>
Woops capps
<Yorlik>
I could use gsl::span though.
<Yorlik>
I came to the conclusion, that there is no way I can easily/trivially take ownership of such a construct.
<hkaiser>
Yorlik: well std::span is a small type, you could create your own, but if you pull in gsl anyways, so yeah - use that
<Yorlik>
I am thinking about making a struct which wraps a unique_ptr with custom deleter for the *start and a span for the acess to have an owning object.
<Yorlik>
I just wanted to ask you about your input to such a situation.
<Yorlik>
Unfortunately there is no way for vector to take ownership of such a thing.
<Yorlik>
Especially when size is dynamic.
<hkaiser>
serialize_buffer is there as well
<hkaiser>
it can be owning or non-owning, as needed
<hkaiser>
it's essentially just what you need
<hkaiser>
a pair (ptr, size)
<Yorlik>
Can you construct it without copying the data form *start, size?
<Yorlik>
I have a feeling there's a treasure trove of stuff to make accessible in HPX
<hkaiser>
Yorlik: the modularization effort we've put in over the last 3 years started off from exactly this motivation
<Yorlik>
You'll get there. Time to find more sponsors ;)
<hkaiser>
indeed
<Yorlik>
hkaiser: What about serialize_buffer const as a view into const data with taking ownership: Could that make sense? In the moment it looks like it will always throw.
<hkaiser>
Yorlik: let's change whatever needs to be changed
<Yorlik>
hkaiser: I don't currently have a use case for this - just thought there's not really a reason not to have that option. The problem I see is, that any non const member function would cause issues in that scenario, but the compiuler would probably warn us anyways.
<hkaiser>
Yorlik: we can always create specializations
<Yorlik>
It might even make sense to create an extra construct out of it - it's just too good as a general purpose tool when dealing with old interfaces.
<Yorlik>
It's a bit like a span on steroids.
<Yorlik>
Properties like bounds checking and ownership options are not in the C++20 span IIRC.
<hkaiser>
right, a span is non-owning by design - the only reason serialize_buffer is such an hybrid is to support serialization and owning-deserialization
<hkaiser>
that can't be done with just non-owning facilities
<hkaiser>
frankly, I don't like this conceptional overload, but I don't see another way
<Yorlik>
It might look like a conceptual overload in your context - but it's also very helpful, when working with foreign C'ish interfaces.
<hkaiser>
Yorlik: btw, all modules are exported a HPXInternal::hpx_${modulename}
<hkaiser>
Yorlik: you should be able to consume HPXInternal::hpx_serialization in your project - no guarantees, though
<Yorlik>
I'll give it a try - just in the target link libraries, yes?
<hkaiser>
yes
<Yorlik>
Sweet - trying now
<Yorlik>
hkaiser: It configures and builds :)
<hkaiser>
nice
<Yorlik>
No more linking of stuff I don't need
<Yorlik>
Love it :)
<hkaiser>
Yorlik: I might just re-export HPXInternal::hpx_${modulename} as HPX::${modulename} at some point
<Yorlik>
It's just one line in my cmake code. :)
<hkaiser>
sure
<Yorlik>
hkaiser: Hmmm ... it seems I'm getting missing symbols with my latest checkout (I tried with an older version before which didn't use HPX for real) ... gotta do some digging - it might not be as easy as it looked initially.
<Yorlik>
Switching back to full HPX solved it - so there IS an issue.
<Yorlik>
I guess I'll need some modules to satisfy dependencies of serialization.
<john98zakaria[m]>
Why is shared_mutex not in hpx/synchronization ?