LWN: Comments on "Workqueues get a rework"

Workqueues get a rework

dibacco73 — Fri, 22 Jun 2007 20:38:22 +0000

If I understand correctly, the workqueue API are very uncomfortable. If I queue_work the same task (function) that is already in the queue with a different parameter (data), it is rejected, why is there not an API to queue a work that copies the structure instead of simply using its pointer? Or probably is better that the user kmalloc the work and then, when the work is completed, the work is freed.

Bye,
Antonio.

Workqueues get a rework

aleXXX — Thu, 30 Nov 2006 21:53:51 +0000

Yes, struct delayed_work and struct work_struct sucks.
IMO it should be struct delayed_work_struct and struct work_struct or
just struct delayed_work and struct work.

Alex

Workqueues get a rework

Randakar — Thu, 30 Nov 2006 14:44:13 +0000

If you read Morton's complaint, he's replying to this:

David Howells <dhowells@redhat.com> wrote:

> These patches shrink work_struct by 8 of the 12 words it ordinarily
> consumes.

So that would be saving 8 * 8 = 64 bytes.
Not bad at all.

Workqueues get a rework

dvrabel — Thu, 30 Nov 2006 10:55:24 +0000

You'd think that while changing the API they'd drop the redundant _struct in struct work_struct etc.

Workqueues get a rework

kzin — Thu, 30 Nov 2006 10:54:28 +0000

...so how much did it save? We go down from 96 bytes on 64-bit machines to what?

Workqueues get a rework

eskild — Thu, 30 Nov 2006 10:14:50 +0000

Ok, I know this won't be at the top of the list of "most important posts on LWN, ever", but anyway: In my native language, Danish, "nar" means "fool". So "DECLARE_WORK_NAR" initially caught my eye and my coffeine-overloaded brain read it as "Declare a work fool?!" It's funny, it's so easy to use a spelling or abbreviation that's "interesting" in at least one other foreign language. Someone I know created an in-house tool with a name aimed at conveying "speed" to the users. Well, speed in Danish is "fart". Not good. Not good at all. :-)