Dolphin X6 getLastError
Locked
12
12
 
|
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Error.JPG (201K) |
|
Kiko
Sera que se hizo otra llamada a otro mensaje que usa el SO? entonces te cambia el valor del getLastError? se me ocurren 2 cosas. 1) que lo setees si mal no recurdo setLastError: 2) que lo hagas dentro de un critical para q no te interrumpan el el scheduler. saludos MDC 2010/8/25 Jose Gregoris <[hidden email]>
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
En general no se puede* llamar explicitamente a GetLastError() desde un FFI porque puede suceder cualquier cosa entre las dos llamadas a funcion... si tenes a mano la ultima version de VisualWorks, fijate el ultimo apendice de la guia de DLLCC. Hay un monton de otras cosas que tampoco se pueden* hacer.
Andres. * por supuesto que se "puede", pero el problema es que no "funciona" :)... 2010/8/25 Juan <[hidden email]> Kiko -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Andres:
En la documentacion de GetLastError dice que es devuelve el ultimo error en el thread que llama a la funcion. Qué posibilidades ves que en un Smalltalk como Dolphin cambie el thread si la llamada a GetLastError se produce un statement mas abajo?
Saludos GallegO El 25 de agosto de 2010 18:28, Andres Valloud <[hidden email]> escribió: En general no se puede* llamar explicitamente a GetLastError() desde un FFI porque puede suceder cualquier cosa entre las dos llamadas a funcion... si tenes a mano la ultima version de VisualWorks, fijate el ultimo apendice de la guia de DLLCC. Hay un monton de otras cosas que tampoco se pueden* hacer. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Jose Gregoris
Kiko:
Por las dudas manda el valor al Transcript porque una vez abierto el debugger pasaron miles de cosas ya. Saludos GallegO
-- El 25 de agosto de 2010 14:08, Jose Gregoris <[hidden email]> escribió:
To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Sebastian Calvo
Como sabes si no hubo un process switch en Smalltalk a otro proceso con mas prioridad que el tuyo, y que ese proceso no llamo tambien a GetLastError()? Como sabes si la maquina virtual no llamo a GetLastError() por la suya para procesar eventos de red despues de llamar a SomeFunction() pero antes de volver a Smalltalk, por ejemplo? El problema basico es que hacer
| returnValue errorCode | returnValue := self callSomeFunction. returnValue = 0 ifFalse: [^value]. errorCode := self callGetLastError. self functionFailedWith: errorCode no es atomico con respecto a process switches o a actividades de la maquina virtual. Por lo tanto, en general es incorrecto (o por lo menos peligroso) llamar a GetLastError() directamente desde un FFI. Andres. 2010/8/26 GallegO <[hidden email]> Andres: -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
El 26 de agosto de 2010 16:03, Andres Valloud <[hidden email]> escribió: Como sabes si no hubo un process switch en Smalltalk a otro proceso con mas prioridad que el tuyo Existen formas de detectar cambios de contexto (no muchas, pero existen). Saludos, Hernán -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
En el caso general, como harias para detectar que otro proceso
interrumpio al proceso que esta por llamar a GetLastError(), y que ese proceso que interrumpio al otro llamo a GetLastError() antes de que el procesus interruptus llamara a GetLastError()? Como sabes que el proceso que interrumpio al otro no va a hacer become: o lo que fuera para que la interrupcion sea invisible? Y aun asi no alcanza para saber que hizo la maquina virtual en el medio... 2010/8/26 Hernán Morales Durand <[hidden email]>: > > El 26 de agosto de 2010 16:03, Andres Valloud <[hidden email]> > escribió: >> >> Como sabes si no hubo un process switch en Smalltalk a otro proceso con >> mas prioridad que el tuyo > > Existen formas de detectar cambios de contexto (no muchas, pero existen). > Saludos, > > Hernán > > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Andres Valloud-5
Andres,
gracias por la aclaración, es verdad es un tanto peligroso, aún así es ampliamente usado, supongo que eso hace que a veces se informe cualquier error. Lo mismo pasa, y es mucho mas gracioso, con Float invalidOperation cuando alguien interrumpe, realiza un calculo, no limpia los flags del coprocesador y en Smalltalk nos da un error como si hubiera una Float exception.
Suele pasar bastante con los ocx. Saludos GallegO El 26 de agosto de 2010 16:03, Andres Valloud <[hidden email]> escribió: Como sabes si no hubo un process switch en Smalltalk a otro proceso con mas prioridad que el tuyo, y que ese proceso no llamo tambien a GetLastError()? Como sabes si la maquina virtual no llamo a GetLastError() por la suya para procesar eventos de red despues de llamar a SomeFunction() pero antes de volver a Smalltalk, por ejemplo? El problema basico es que hacer To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
[hidden email]>:
>> >> El 26 de agosto de 2010 16:03, Andres Valloud <[hidden email]> >> escribió: >>> >>> Como sabes si no hubo un process switch en Smalltalk a otro proceso con >>> mas prioridad que el tuyo >> >> Existen formas de detectar cambios de contexto (no muchas, pero existen). >> Saludos, >> >> Hernán >> >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Dolphin X6 getLastError
|
|
Esa aplicacion no va a detectar process switches en Smalltalk porque
todos los procesos se ejecutan (pueden ejecutarse) en el mismo thread nativo... aparte, el producto ese es un profiler. No me parece que adoptar un profiler para detectar cuando se puede llamar o no a GetLastError() sea compatible con el uso diario que le damos a Smalltalk. 2010/8/27 Hernán Morales Durand <[hidden email]>: > Tal vez te sea de ayuda la experiencia de esta gente: > > http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5227185&tag=1 > > Saludos, > > Hernán > > El día 26 de agosto de 2010 18:06, Andres Valloud > <[hidden email]> escribió: >> En el caso general, como harias para detectar que otro proceso >> interrumpio al proceso que esta por llamar a GetLastError(), y que ese >> proceso que interrumpio al otro llamo a GetLastError() antes de que el >> procesus interruptus llamara a GetLastError()? Como sabes que el >> proceso que interrumpio al otro no va a hacer become: o lo que fuera >> para que la interrupcion sea invisible? Y aun asi no alcanza para >> saber que hizo la maquina virtual en el medio... >> >> 2010/8/26 Hernán Morales Durand <[hidden email]>: >>> >>> El 26 de agosto de 2010 16:03, Andres Valloud <[hidden email]> >>> escribió: >>>> >>>> Como sabes si no hubo un process switch en Smalltalk a otro proceso con >>>> mas prioridad que el tuyo >>> >>> Existen formas de detectar cambios de contexto (no muchas, pero existen). >>> Saludos, >>> >>> Hernán >>> >>> >>> -- >>> To post to this group, send email to [hidden email] >>> To unsubscribe from this group, send email to >>> [hidden email] >>> >>> http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to [hidden email] >> >> http://www.clubSmalltalk.org > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Yo no hablé de la problemática en Smalltalk, sino de detectar cambios
de contexto. Tal vez te sirva la técnica que usaron y puedas adaptarla a tu trabajo. No esperes encontrar un paper en donde la solución esté cocinada y masticada, y menos para Smalltalk. Saludos El día 27 de agosto de 2010 18:32, Andres Valloud <[hidden email]> escribió: > Esa aplicacion no va a detectar process switches en Smalltalk porque > todos los procesos se ejecutan (pueden ejecutarse) en el mismo thread > nativo... aparte, el producto ese es un profiler. No me parece que > adoptar un profiler para detectar cuando se puede llamar o no a > GetLastError() sea compatible con el uso diario que le damos a > Smalltalk. > > 2010/8/27 Hernán Morales Durand <[hidden email]>: >> Tal vez te sea de ayuda la experiencia de esta gente: >> >> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5227185&tag=1 >> >> Saludos, >> >> Hernán >> >> El día 26 de agosto de 2010 18:06, Andres Valloud >> <[hidden email]> escribió: >>> En el caso general, como harias para detectar que otro proceso >>> interrumpio al proceso que esta por llamar a GetLastError(), y que ese >>> proceso que interrumpio al otro llamo a GetLastError() antes de que el >>> procesus interruptus llamara a GetLastError()? Como sabes que el >>> proceso que interrumpio al otro no va a hacer become: o lo que fuera >>> para que la interrupcion sea invisible? Y aun asi no alcanza para >>> saber que hizo la maquina virtual en el medio... >>> >>> 2010/8/26 Hernán Morales Durand <[hidden email]>: >>>> >>>> El 26 de agosto de 2010 16:03, Andres Valloud <[hidden email]> >>>> escribió: >>>>> >>>>> Como sabes si no hubo un process switch en Smalltalk a otro proceso con >>>>> mas prioridad que el tuyo >>>> >>>> Existen formas de detectar cambios de contexto (no muchas, pero existen). >>>> Saludos, >>>> >>>> Hernán >>>> >>>> >>>> -- >>>> To post to this group, send email to [hidden email] >>>> To unsubscribe from this group, send email to >>>> [hidden email] >>>> >>>> http://www.clubSmalltalk.org >>> >>> -- >>> To post to this group, send email to [hidden email] >>> To unsubscribe from this group, send email to [hidden email] >>> >>> http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to [hidden email] >> >> http://www.clubSmalltalk.org > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Andres Valloud-5
On 08/26/2010 06:06 PM, Andres Valloud wrote:
> En el caso general, como harias para detectar que otro proceso > interrumpio al proceso que esta por llamar a GetLastError(), si, no se puede me parece en el caso general. Por otro lado, no es solo si llamaron a GetLastError(). Si llamaron a cualquier otra función de Windows, que resetea el GetLastError() también. El GetLastError() es único por cada thread de Windows, si dos procesos nativos se interrumpen mutuamente, igual el GetLastError() de cada uno está a salvo. El tema es que en Smalltalk pasan dos cosas: . green threads, donde un solo thread nativo aloja más de un hilo de ejecución, y entonces se puede corromper el last error. . La VM también hace cosas entre bytecode y bytecode, método y método, etc. Si entre que llamas a la API y llamas a GetLastError(), por ejemplo, caé un GC, y el GC le devuelve memoria al OS (VirtualProtect(), mmap(), etc). eso va a cambiar el GetLastError(). como dijo Andres de entrada, no es seguro llamar a GetLastError() via FFI o algún otro tipo de API call. Y la VM tendría que proveer un mecanismo seguro de hacerlo (básicamente, llamar a GetLastError() después de cada API call, y guardarlo para uso futuro) saludos, gera -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Hola:
Se puede resolver si la VM copia en cada swith a una i.v. del process el status no? Saludos GallegO El día 27 de agosto de 2010 18:50, Gerardo Richarte <[hidden email]> escribió: > On 08/26/2010 06:06 PM, Andres Valloud wrote: >> En el caso general, como harias para detectar que otro proceso >> interrumpio al proceso que esta por llamar a GetLastError(), > si, no se puede me parece en el caso general. Por otro lado, no > es solo si llamaron a GetLastError(). Si llamaron a cualquier otra > función de Windows, que resetea el GetLastError() también. > > El GetLastError() es único por cada thread de Windows, si dos > procesos nativos se interrumpen mutuamente, igual el GetLastError() > de cada uno está a salvo. El tema es que en Smalltalk pasan dos cosas: > > . green threads, donde un solo thread nativo aloja más de un hilo de > ejecución, y entonces se puede corromper el last error. > . La VM también hace cosas entre bytecode y bytecode, método y > método, etc. Si entre que llamas a la API y llamas a GetLastError(), > por ejemplo, caé un GC, y el GC le devuelve memoria al OS (VirtualProtect(), > mmap(), etc). eso va a cambiar el GetLastError(). > > como dijo Andres de entrada, no es seguro llamar a GetLastError() > via FFI o algún otro tipo de API call. Y la VM tendría que proveer un > mecanismo seguro de hacerlo (básicamente, llamar a GetLastError() > después de cada API call, y guardarlo para uso futuro) > > saludos, > gera > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Gerardo Richarte
Por eso en DLLCC hay un pragma para llamar a una funcion de Windows
devolviendo el GetLastError() si la funcion falla... el pragma es _wincall. Para *nix, tambien hay _syscall para poder obtener el valor de errno asociado a la funcion que acabas de llamar via el FFI. Lamentablemente, en VisualWorks hay un metodo para llamar a GetLastError() directamente en la clase Win32SystemSupport. Eso es un error y me gustaria que para la version nueva eso no este mas :)... 2010/8/27 Gerardo Richarte <[hidden email]>: > On 08/26/2010 06:06 PM, Andres Valloud wrote: >> En el caso general, como harias para detectar que otro proceso >> interrumpio al proceso que esta por llamar a GetLastError(), > si, no se puede me parece en el caso general. Por otro lado, no > es solo si llamaron a GetLastError(). Si llamaron a cualquier otra > función de Windows, que resetea el GetLastError() también. > > El GetLastError() es único por cada thread de Windows, si dos > procesos nativos se interrumpen mutuamente, igual el GetLastError() > de cada uno está a salvo. El tema es que en Smalltalk pasan dos cosas: > > . green threads, donde un solo thread nativo aloja más de un hilo de > ejecución, y entonces se puede corromper el last error. > . La VM también hace cosas entre bytecode y bytecode, método y > método, etc. Si entre que llamas a la API y llamas a GetLastError(), > por ejemplo, caé un GC, y el GC le devuelve memoria al OS (VirtualProtect(), > mmap(), etc). eso va a cambiar el GetLastError(). > > como dijo Andres de entrada, no es seguro llamar a GetLastError() > via FFI o algún otro tipo de API call. Y la VM tendría que proveer un > mecanismo seguro de hacerlo (básicamente, llamar a GetLastError() > después de cada API call, y guardarlo para uso futuro) > > saludos, > gera > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Yendo un poco mas a fondo... en general el tema con esos pragmas es
que no cubren todas las funciones habidas y por haber. Por ejemplo, en Windows cuando usas sockets tenes que llamar a WSAGetLastError() en vez de GetLastError()... se imaginan que no se puede andar agregando _wsawincall, _pirulocall, _mongocall etc todo el tiempo para contemplar todos los casos posibles. Por eso es que, si la cosa se pone peliaguda, lo mejor es ni usar un FFI y escribir primitivas directamente. Es mas, con primitivas podes asumir la estructura del objeto que recibe el metodo que invoca la primitiva, y entonces el marshalling lo optimiza el compilador de C para esa llamada particular. Con un poco de cuidado, hasta te podrias guardar las cosas en un byte array y entonces ni marshalling hay... 2010/8/27 Andres Valloud <[hidden email]>: > Por eso en DLLCC hay un pragma para llamar a una funcion de Windows > devolviendo el GetLastError() si la funcion falla... el pragma es > _wincall. Para *nix, tambien hay _syscall para poder obtener el valor > de errno asociado a la funcion que acabas de llamar via el FFI. > > Lamentablemente, en VisualWorks hay un metodo para llamar a > GetLastError() directamente en la clase Win32SystemSupport. Eso es un > error y me gustaria que para la version nueva eso no este mas :)... > > 2010/8/27 Gerardo Richarte <[hidden email]>: >> On 08/26/2010 06:06 PM, Andres Valloud wrote: >>> En el caso general, como harias para detectar que otro proceso >>> interrumpio al proceso que esta por llamar a GetLastError(), >> si, no se puede me parece en el caso general. Por otro lado, no >> es solo si llamaron a GetLastError(). Si llamaron a cualquier otra >> función de Windows, que resetea el GetLastError() también. >> >> El GetLastError() es único por cada thread de Windows, si dos >> procesos nativos se interrumpen mutuamente, igual el GetLastError() >> de cada uno está a salvo. El tema es que en Smalltalk pasan dos cosas: >> >> . green threads, donde un solo thread nativo aloja más de un hilo de >> ejecución, y entonces se puede corromper el last error. >> . La VM también hace cosas entre bytecode y bytecode, método y >> método, etc. Si entre que llamas a la API y llamas a GetLastError(), >> por ejemplo, caé un GC, y el GC le devuelve memoria al OS (VirtualProtect(), >> mmap(), etc). eso va a cambiar el GetLastError(). >> >> como dijo Andres de entrada, no es seguro llamar a GetLastError() >> via FFI o algún otro tipo de API call. Y la VM tendría que proveer un >> mecanismo seguro de hacerlo (básicamente, llamar a GetLastError() >> después de cada API call, y guardarlo para uso futuro) >> >> saludos, >> gera >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to [hidden email] >> >> http://www.clubSmalltalk.org > -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Andres Valloud-5
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Andres Valloud-5
El día 28 de agosto de 2010 02:59, Andres Valloud
<[hidden email]> escribió: > Yendo un poco mas a fondo... en general el tema con esos pragmas es > que no cubren todas las funciones habidas y por haber. Por ejemplo, > en Windows cuando usas sockets tenes que llamar a WSAGetLastError() en > vez de GetLastError()... se imaginan que no se puede andar agregando > _wsawincall, _pirulocall, _mongocall etc todo el tiempo para > contemplar todos los casos posibles. Por eso es que, si la cosa se > pone peliaguda, lo mejor es ni usar un FFI y escribir primitivas > directamente. ¿Qué te impide implementar un mecanismo de sincronización por exclusión mutua o por condición a nivel FFI? Hernán -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Jose Gregoris
No vi eso que decis, pero en general estaria bueno usar _wincall :)...
2010/8/30 Jose Gregoris <[hidden email]>
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by hernanmd
Por eso dije que en DLLCC existe el pragma _wincall. El problema, sin
embargo, es que a veces tenes que llamar a WSAGetLastError(), o a CuchuflitoGetLastError(), o la convencion de indicacion de errores es diferente para un DLL que hizo algun otro, y en general no se puede andar agregando _mongocall, _juanperezcall y otros pragmas asi tan facil. Para esos, lo mejor es escribir una primitiva chiquita en C y llamarla desde la imagen. 2010/8/30 Hernán Morales Durand <[hidden email]>: > El día 28 de agosto de 2010 02:59, Andres Valloud > <[hidden email]> escribió: >> Yendo un poco mas a fondo... en general el tema con esos pragmas es >> que no cubren todas las funciones habidas y por haber. Por ejemplo, >> en Windows cuando usas sockets tenes que llamar a WSAGetLastError() en >> vez de GetLastError()... se imaginan que no se puede andar agregando >> _wsawincall, _pirulocall, _mongocall etc todo el tiempo para >> contemplar todos los casos posibles. Por eso es que, si la cosa se >> pone peliaguda, lo mejor es ni usar un FFI y escribir primitivas >> directamente. > > ¿Qué te impide implementar un mecanismo de sincronización por > exclusión mutua o por condición a nivel FFI? > > Hernán > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
«
Return to Español (Spanish)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |