Re: Appendix: multithreating HOWTO ? :)
Frank Kotler <[email protected]> Sun, 23 Aug 2009 15:18:48 -0400
| Newsgroups | org.kernel.vger.linux-assembly |
|---|---|
| Message-ID | <[email protected]> |
£ukasz wrote: > thanks for answer, im experiment with system clone ( actualy fork i found in many manuals ) but i dont understand Frakns last sentence > "Well, they *told* us not to do it that way. :)", to program multiproceses with fork ? Any way is there any way to make share memory for proceses ? Just a "joke". I meant, using the int 80h (or syscall) interface. We're "supposed" to use the C interface. Like Claudio, I'm a "32-bit guy" - and I don't know how to do multithreading even on 32-bit. But I think if you're going to use 64-bit registers, you'll have to use 64-bit sys_call numbers, put the parameters in regs compatible with the 64-bit ABI, and use "syscall" instead of "int 0x80". I don't think what you're doing will work, but I'm not equipped to try it. You can share memory between processes by memmapping a region and flagging it MAP_SHARED (sys_fork or even separate executables). I *think* for threads, you'd want sys_clone, and all memory would be shared(?). I think your issue is going to be keeping your threads from read/writing the same memory at the same time. I'm a "single CPU guy", too, but I think multi-CPU is going to be "even worse". I made an example using pthread_create - not that I want to use it either, but to see what it does for us. Easier to read the source, I'm sure, but no, I ran it in strace. Doing a bunch of "signal related" stuff I don't understand. I'm afraid I'm going to have to learn more about "signals" before I can proceed with this... For those of us who need to learn about 64-bit programming, there's a tutorial: <http://www.vikaskumar.org/wiki/index.php?title=X86-64_Tutorial> Came across this, that looked interesting, too: <http://milw0rm.org/papers/110> Best, Frank -- To unsubscribe from this list: send the line "unsubscribe linux-assembly" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html