develooper Front page | perl.perl5.porters | Postings from August 2001

Threading semantics

Thread Previous | Thread Next
Arthur Bergman
August 8, 2001 03:06
Threading semantics
Message ID:
There are some outstanding issues with threads right now. Comments very welcome.

A) Request for threads->kill, to kill a given thread, is this something we should have? Should we try to do what posix does with all these cancelation points and cancelation callbacks? We know what mutexes we own so we can make sure they are all canceled. My belief that this is needed.

On unix this can be done by a signal(?), I don't know about Win32.

B) Right now, it seems like the parent interpreter must still stick around for it childrens. I think it will have to stay like this for 5.8 and something that can be fixed for 5.10 with a global SV arena, right now we use the first interpreter as the store

C) Quitting the main thread, now this kills all threads (as normal threading). However this usually comes at bad times. And we don't get proper cleanup (and segfaults9. I think we should wait for all threads to finish, letting the user to kill them.

D) lock, unlock, share, are now implmented in threads::shared, You have to manually unlock(), it is not scope based. I think the implmentation of lock() unlock() should perhaps move into pp_lock and pp_unlock, share() cond_*() needs new reference protptype.

E) sharing probably needs a new kind of magic, but I think that can wait until we see sharing working as we want

F) a shared blessed object, the destructor should be called once for each thread, or in the thread where it actually is destroyed? Is there a way to catch blessings to magic/tied variables? If not I guess we can not rebless shared data structures.

Comments very welcome.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About