Hi ! supreet wrote:
OK ... sorry ... I shud've written clone() ... thanks for correcting me :)Making such an effort is a great thing. But take note that addressing it as Light Weight Process LWP's is not really applicable in linux. (reasons)
1) Kernel is involved in case initialization of thread through syscall clone(2)
Go deeper and you'll find sys_clone() is written on top of do_fork() and so is sys_fork() ... and do_fork() takes 'clone_flags' as params ... so a lot of scope for threads anyway.
(Consider this ... VMS has a more abstract thread model, and FreeVMS is built on top of Linux sources ... although incomplete ... but the very fact that ppl are trying shud be encouraging. I dont want to get involved with cloning VMS coz it's ... well ... too difficult :( . )
2) you see threads as seprate entities in process tree.Let it just the remain the way it is for the time being ... if the need arises
I am willing to head into /usr/src/linux for some 'real' hacking :)
3) Resource cost for fork() does not hit the roof compared to clone()But fork() would (logically) replicate the execution context ... and then one has
to exec() to change the image whereas clone() gives you the opportinity to schedule
individual functions(). Thats what our primary focus remains.
I would like to get involved
Supreet
Hey ... thats great ... so do you have a plan or wanna start the way I plan ?
See POSIX threads are written around clone(), one strategy is commonplace,
i.e. to wrap pthread etc in classes. But I suggest we start clean and build classes
around clone() itself and share semaphores across clones to hide a shm area where
the clones actually read/write synchronization data ?
The reason being ... pthreads call the clone() library routine ... the lib routine
in turn gets into k-land. If we wrap pthreads, then we have to face the phtread
boundary too. I want to take a short cut to clone() straight away and build classes
around clone() ... ( OTOH ... pthreads are a well tested standardized libs )
So what do you suggest ? Are you coming to the meeting ? We can discuss it there .
Regards, Gagan.
================================================ To unsubscribe, send email to [EMAIL PROTECTED] with unsubscribe in subject header. Check archives at http://www.mail-archive.com/ilugd%40wpaa.org
