Re^2: RFC: Proposed module POSIX::Yield

Well for one, threads::yield will only work on a perl binary with threads support, and AFAIK it's not actually very well defined what threads::yield does, especially in a single-threaded program.

As for the OP's question about Inline::C vs XS, I'd recommend porting the module to XS if you want to release it to the public, just because it removes a couple of dependencies. Once you have a working Inline::C module, porting to XS isn't very hard.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Comment on Re^2: RFC: Proposed module POSIX::Yield

Replies are listed 'Best First'.
Re^3: RFC: Proposed module POSIX::Yield by tirwhan (Abbot) on Dec 02, 2005 at 16:28 UTC
Thanks. Do you think it'd be worthwhile doing that? I still like the idea of being able to call sched_yield explicitly (despite dave_the_m's very valid objection), and it'd be useful on older Perl versions as well. But I don't want to pollute CPAN with useless stuff. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan	[reply]
Re^4: RFC: Proposed module POSIX::Yield by Joost (Canon) on Dec 02, 2005 at 19:33 UTC
I think a module like this could be useful in certain situations, even though I've never had any reason to use this syscall (but to be honest, I didn't even know it existed). So I'd say go for it. The name is probably OK. At least, there is some precedent in POSIX::strptime and the POSIX::RT modules. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]