Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 06 16:03
    zicklag commented #3151
  • Apr 06 03:13
    kvark commented #3151
  • Apr 06 00:35
    zicklag commented #3151
  • Apr 06 00:27
    zicklag synchronize #3151
  • Apr 06 00:23
    zicklag synchronize #3151
  • Apr 06 00:19
    zicklag synchronize #3151
  • Apr 06 00:18
    zicklag commented #3151
  • Apr 05 23:04
    grovesNL commented #3151
  • Apr 05 22:32
    zicklag commented #3151
  • Apr 05 22:09
    zicklag synchronize #3151
  • Apr 05 22:01
    zicklag commented #3151
  • Apr 05 21:03
    zicklag edited #3151
  • Apr 05 21:00
    zicklag synchronize #3151
  • Apr 05 20:14
    zicklag synchronize #3151
  • Apr 05 20:09
    zicklag edited #3151
  • Apr 05 20:08
    zicklag synchronize #3151
  • Apr 05 19:35
    kvark commented #2418
  • Apr 05 19:27
    BrandonDyer64 commented #2418
  • Apr 05 18:59
    hgallagher1993 commented #3200
  • Apr 05 18:56
    zicklag synchronize #3151
Coraline Sherratt
@removed~csherratt
We are consumed quickly and then left at the party for the host to kickout when we have over stayed our welcome? :P
Chip Collier
@photex
hahaha
Dzmitry Malyshau
@kvark
@bjz congrats with a free ad on the "crates.io" ;)
Brendan Zabarauskas
@brendanzab
:)
Dzmitry Malyshau
@kvark
@bjz @csherratt thanks for having a look at #21
Dzmitry Malyshau
@kvark

Could both of you explain what you mean now? :)

@bjz how does having a channel per return type change the interface with the client?
@csherratt something like that?

let load_handle = client.create_program(...);
...
let prog = client.retrieve_program(load_handle);
Chip Collier
@photex
My suggestion tl;dr: Move the recv into another method that can be called after all the submissions.
Dzmitry Malyshau
@kvark
@photex how do we enforce the queue order of requests vs receives then?
Chip Collier
@photex
why would you?
you can't enforce that in either case
one idea though, is to index the submits
if you really need to
I've had to do that to implement a parmap over a vector for instance
but I didn't think that was the nature of these calls
Brendan Zabarauskas
@brendanzab
@photex no cat! you are boring now :(
Chip Collier
@photex
haha
I'm zen
Dzmitry Malyshau
@kvark
cat-zen
Chip Collier
@photex
I'll draw some ears on it
Brendan Zabarauskas
@brendanzab
@photex I wan splodey cat again :(
Chip Collier
@photex
ok ok
lemme find it
brendanzab @bjz is working on a bad presentation
Dzmitry Malyshau
@kvark
@bjz you've got a rather large scope...
Brendan Zabarauskas
@brendanzab
aye
dunno if I should redefine it :(
Chip Collier
@photex
I like the enso on this page though
wish gitter would let me specify an avatar without github
lol
brendanzab @bjz likes seeing lots of cats
Brendan Zabarauskas
@brendanzab
:cat2: :cat2: :cat2: :cat2: :cat2: :cat2:
sorry for derailing the discussion :smile:
Chip Collier
@photex
ok splodey is back... no idea when gitter updates it
Dzmitry Malyshau
@kvark
@photex Your proposal on #21 makes sense too me, but if we go this route, why do we even need a Client struct? The client would just get the duplex stream end to work with (or something that implements Deref<DuplexStream<..>>). That's not as convenient as it is now,.. but would also solve #9 .
Brendan Zabarauskas
@brendanzab
@photex :heart:
Coraline Sherratt
@removed~csherratt
@kvark If you let the client enumerate the handle you can avoid the round trip. CreateFoo(unique number, args). Then later when you want to use the handle, UseFoo(same unique handle, args). Since it is in a FIFO the server will see the CreateFoo before the UseFoo and it should work.
The creation of the unique number would need to be transparent to the client. It's just a implementation detail.
Coraline Sherratt
@removed~csherratt
If the handle in this case was actually just an pointer, the server would not even need to look up anything.
Dzmitry Malyshau
@kvark
@csherratt What exactly do you mean by "client enumerate the handle"? Overall, I kinda like this solution. There would be no need to wait synchronously for the user. From his perspective, once something is queried for creation, it exists. Our Client would have to make sure everything is loaded by the time it is used. A big question here is whether this checks are going to be any heavy for us to bear (because most of the time Use function is called the resource is already there).
Coraline Sherratt
@removed~csherratt
What is the content of the handle exactly?
Dzmitry Malyshau
@kvark
So far the handle is represented as (id, generation) pair (see @photex data.rs). Not sure if we are going to add some custom info to it later on the way (depending on the type)
Coraline Sherratt
@removed~csherratt
hmm
So when I meant by enumerate the handle is that the client figures out the Id of the handle, it does not have to wait for the server to figure it out.
Not sure of the generation field...
The id can just be bumping an atomic variable.
Dzmitry Malyshau
@kvark
@csherratt I don't think the figuring out of the ID takes long enough to defer it :) We are talking about deferring program linking, buffer and texture loading, and such. So the user may call Create() and get the unique handle back from Client.
Coraline Sherratt
@removed~csherratt
Ah that makes more sense.
So if you are doing an async program linking, how do we know if it failed or not?
Dzmitry Malyshau
@kvark
@csherratt Good question. Here comes the proposal to solve it: error channel. It's a simple one-side channel that will be used to report errors back to the user. The errors are gonna be defined as enum Error {}, and the user is going to be responsible for checking those and make arrangements accordingly. Does that sound good to @bjz @photex ?