On 18 July 2011 19:32, Henrik Johansen <henrik.s.johansen@veloxit.no> 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 <siguctua@gmail.com> 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.