On 18 July 2011 19:32, Henrik Johansen <[email protected]> wrote: > You could - however, unlike exception handling, process-local variables are > not part of ANSI. > Which means it's a safer choice for Seaside from a portability POV. > Yes, but seaside using grease layer to deal with dialect-specific stuff. So it is perfectly reasonable to use more effective feature(s) if they are available.
> Speaking of which, referring to my last post when Danie raised the issue, is > there any reason we don't copy the process environment when forking? > as any feature it needs to have a real use case. Because if its not used by anything, we don't have feedback and it even makes little sense to support it or change it. Without real use case i cannot clearly say, if environment should be inherited when you forking or not. If we draw a parallel with OS process - then yes, in OSes (at least unix ones) they inherit environment and file handles etc , when forking. But if we draw a parallel to threads, the thread-specific storage is clean for new thread. So i really don't know which approach is better without looking at real use case. Unfortunately, we don't have anything which using it now :( > Cheers, > Henry > > On 18. juli 2011, at 16:47, Igor Stasenko <[email protected]> wrote: > >> For instance, in Seaside (if i remember correctly) it creates a >> separate process for handling request. >> And so, for dynamic variables you can use a process-specific storage , >> provided by >> Process>>environmentAt: and environmentAt:put:, rather than using >> exceptions to access dynamic variable values. >> Like that, you don't need to use exceptions and moreover it will work >> much faster, because unwinding stack each time you accessing the state >> is costly! >> > > -- Best regards, Igor Stasenko AKA sig.
