3 ms·

From my understanding (and also mentioned by someone in the comments on the RFC I linked), while you can do things to the threads by just directly calling throu

by dljsjr 9y ago

From my understanding (and also mentioned by someone in the comments on the RFC I linked), while you can do things to the threads by just directly calling through to C, what you end up with is a thread that doesn't have all of the Rust runtime niceties set up on it correctly. I'm just waiting for a full featured version of this functionality to be available in the language, but I was also sort of curious to see what OP's solution to the problem was. And like I mentioned originally, my day job is to maintain code that does the same thing but for Java. I don't wanna have to maintain it in two languages even if one is just a pet project. Since Rust is billing itself as a systems language it makes sense that this will be a feature eventually, and I'm willing to wait patiently. It's not holding me back from anything, it's just a personal curiosity.

steveklabnik 9y ago
Rust doesn’t really have much of a runtime; I’m not sure what niceties you’re thinkjg of :) (I also logged that you talked about this in the issue; even knowing people want this is useful; it’s probably not in std because nobody’s ever really argued they need it!)
- dljsjr 9y ago
  Thanks for taking the time to look at this Steve! I'm not super familiar with threading in Rust, I was just going off comments made in the RFC and what little research I had done at the time I started looking in to it. This was all a few years ago and I know the runtime used to be much heavier so my info could very well be out of date. I know that this is a feature that doesn't impact a large number of people, but for the people that do need it it's pretty important. Being able to do soft real-time threading inside of an RTOS environment like Xenomai or Linux w/ the preemptive kernel (RT) patch in combination with Rust's other safety-oriented features would be a huge boon for embedded developers I think.
  - steveklabnik 9y ago
    Ah ha! So, looking at the issue, at that time, Rust did have a runtime, and green threads. Today, we don't, and just have OS threads. So that's where the miscommunication lies :)
rapsey 9y ago
> while you can do things to the threads by just directly calling through to C, what you end up with is a thread that doesn't have all of the Rust runtime niceties set up on it correctly. That is incorrect. Rust threads are system threads and nothing more. > I'm just waiting for a full featured version of this functionality to be available in the language, but I was also sort of curious to see what OP's solution to the problem was. You will be waiting for a long time. No one is in a rush for that RFC because the functionality exists in crates and through a ffi call if you need it. Rust does not have a large standard library and will never have one as large as Java/C#. This is why the crate system exists.
- dljsjr 9y ago
  >> while you can do things to the threads by just directly calling through to C, what you end up with is a thread that doesn't have all of the Rust runtime niceties set up on it correctly. > That is incorrect. Rust threads are system threads and nothing more. It seems that wasn't the case years ago when I originally researched this and when the RFC I linked was filed. > You will be waiting for a long time. No one is in a rush for that RFC because the functionality exists in crates and through a ffi call if you need it. Rust does not have a large standard library and will never have one as large as Java/C#. This is why the crate system exists. That's fine, I'm not asking for a large standard library nor am I being held back by the absence of these features. I haven't spent a lot of time with Rust but it's on my radar so I was just asking a few questions to try and gather some info. Do note, though, that if a language wants to bill itself as a systems language that these are important features to have available and well-vetted for low-level embedded software development.

by dljsjr 9y ago

steveklabnik 9y ago

Rust doesn’t really have much of a runtime; I’m not sure what niceties you’re thinkjg of :) (I also logged that you talked about this in the issue; even knowing people want this is useful; it’s probably not in std because nobody’s ever really argued they need it!)

dljsjr 9y ago
Thanks for taking the time to look at this Steve! I'm not super familiar with threading in Rust, I was just going off comments made in the RFC and what little research I had done at the time I started looking in to it. This was all a few years ago and I know the runtime used to be much heavier so my info could very well be out of date. I know that this is a feature that doesn't impact a large number of people, but for the people that do need it it's pretty important. Being able to do soft real-time threading inside of an RTOS environment like Xenomai or Linux w/ the preemptive kernel (RT) patch in combination with Rust's other safety-oriented features would be a huge boon for embedded developers I think.
- steveklabnik 9y ago
  Ah ha! So, looking at the issue, at that time, Rust did have a runtime, and green threads. Today, we don't, and just have OS threads. So that's where the miscommunication lies :)

rapsey 9y ago

> while you can do things to the threads by just directly calling through to C, what you end up with is a thread that doesn't have all of the Rust runtime niceties set up on it correctly. That is incorrect. Rust threads are system threads and nothing more. > I'm just waiting for a full featured version of this functionality to be available in the language, but I was also sort of curious to see what OP's solution to the problem was. You will be waiting for a long time. No one is in a rush for that RFC because the functionality exists in crates and through a ffi call if you need it. Rust does not have a large standard library and will never have one as large as Java/C#. This is why the crate system exists.

dljsjr 9y ago
>> while you can do things to the threads by just directly calling through to C, what you end up with is a thread that doesn't have all of the Rust runtime niceties set up on it correctly. > That is incorrect. Rust threads are system threads and nothing more. It seems that wasn't the case years ago when I originally researched this and when the RFC I linked was filed. > You will be waiting for a long time. No one is in a rush for that RFC because the functionality exists in crates and through a ffi call if you need it. Rust does not have a large standard library and will never have one as large as Java/C#. This is why the crate system exists. That's fine, I'm not asking for a large standard library nor am I being held back by the absence of these features. I haven't spent a lot of time with Rust but it's on my radar so I was just asking a few questions to try and gather some info. Do note, though, that if a language wants to bill itself as a systems language that these are important features to have available and well-vetted for low-level embedded software development.