[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230523100331.4070035-1-aliceryhl@google.com>
Date: Tue, 23 May 2023 10:03:30 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: yakoyoku@...il.com
Cc: alex.gaynor@...il.com, aliceryhl@...gle.com,
benno.lossin@...ton.me, bjorn3_gh@...tonmail.com,
boqun.feng@...il.com, gary@...yguo.net, jiangshanlai@...il.com,
linux-kernel@...r.kernel.org, ojeda@...nel.org,
patches@...ts.linux.dev, rust-for-linux@...r.kernel.org,
tj@...nel.org, wedsonaf@...il.com
Subject: Re: [PATCH v1 1/7] rust: workqueue: add low-level workqueue bindings
On 5/19/23 09:04, Martin Rodriguez Reboredo wrote:
> On 5/19/23 06:40, Alice Ryhl wrote:
>> On 5/18/23 16:51, Martin Rodriguez Reboredo wrote:
>>> On 5/17/23 17:31, Alice Ryhl wrote:
>>>> + /// Enqueues a work item.
>>>> + ///
>>>> + /// This may fail if the work item is already enqueued in a workqueue.
>>>
>>> Wouldn't be worth to mention that, if not implied, the item it's going
>>> to be worked on an unbound CPU?
>>
>> I'm not really sure what you mean. Can you elaborate?
>
> I've meant that if it's good to mention that `queue_work_on` is going
> to be called with `WORK_CPU_UNBOUND` so that API users know about it.
Ah, I misunderstood at first. I thought you were commenting on the "This
may fail if ..." sentence. I'll go ahead and add that to the
documentation. I will include it in the next patch set once I have
looked at your other reviews.
This part of the next version will look like this:
+ /// Enqueues a work item.
+ ///
+ /// This may fail if the work item is already enqueued in a workqueue.
+ ///
+ /// The work item will be submitted using `WORK_CPU_UNBOUND`.
+ pub fn enqueue<T: WorkItem + Send + 'static>(&self, w: T) -> T::EnqueueOutput {
Alice
Powered by blists - more mailing lists