in reply to Re^7: Overriding bless for inside-out object safety
in thread Overriding bless for inside-out object safety

The protections are needed even without sharing objects between threads (where changes to an object in one thread are visible in another).

This is only true if

I'm suggesting that neither of these is either desirable nor necessary for threaded applications provided you do not try to use threads as you would forks.

I cannot address your comments regarding fork on win32. With the absence of proper signal emulation; the conflicts with global resources, file handles, sockets, environment, etc.; and the performance penalty that the fork emulation layers upon threading; I (personally) would prefer it if the fork emulation did not exist.

In my attempts to use it, it simply isn't sufficiently compatible with Unix fork to make it usable in for the normal "forking idiom" (Silly forker :).

Of more concern to me is that the requirements imposed by the attempted emulation, have a disastrous effect upon the use of threads as threads. It forces me to jump through hoops to avoid the expensive and unwanted automatic duplication of resources, to be able to get 'virgin' threads without pre-existing baggage.

I realise that the emulation came first and threads (as in ithreads) leverage much of the excellent work that went into the original fork emulation, and I am not detracting from that work, but it would be so much better (for me, and my uses) if I could specify use threads qw[NOCLONE];.

Ie. When I create a thread, give me a virgin interpreter running in that thread and let me create the things I need. Please :)

I've never really understood the fork and exec idiom anyway. Why bother going through the process of duplicating the current process in to an exact clone--even with COW--if the next thing you are going to do is throw it all away and load a completely different executable image into that process? Why not just load the image into a new process and have done with it?

I know fork & exec isn't the only use of fork, but it is the most prevalent.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^9: Overriding bless for inside-out object safety
by xdg (Monsignor) on Jan 05, 2006 at 00:54 UTC
    This is only true if...

    I can agree with that. However, in writing an inside-out helper for others, I feel I have to plan if not for the worst case, at least for many of the suboptimal practices that people may use. (Insofar as Perl will let me -- I can't do much about pseudo-forks on Win32 Perl 5.6.) So while I agree, it doesn't let me off the hook of helping people with automatic support for CLONE.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
[d/l]

In Section Meditations