Re: RES: package system modification (module loaders)

[Diego Nehab <diego@...>]

Hi,

> > The posibility of a library or something else requiring modification to
> > the Lua core or to the interpreter executable has nothing to do with the
> > package proposal.
>
> Sure it does -- packages are designed to help load
> extensions in a standard way.

That's what the package proposal does and it does it well. The problem is
your definition of package. For me, it has always been something that
uses the standard Lua C API or the Lua standard libraries or perhaps
packages.

> How? You can't just do a wait loop.

What are you talking about? You use socket.select to block until there
is something to do. When there is something to do, you use non-blocking
I/O to get and send everythying you can.  You can have many lines of
flow cooperating like this by means of coroutines. There is no busy
wait, no threads. It's safer, easier to understand, easier to debug, AND
faster.

> > On Windows at
> > least I read somewhere that it can be catastrophic...
>
> I'm sure this isn't the only bug in Windows ..
> if this doesn't work, Windows is screwed --
> you *have* to be able to cancel a blocked thread.
> [If you can't you'd have to kill the whole processes]

Saying you have to be able doesn't make it so. LuaSocket is about
portability. Most people can't afford not to use Windows, as sad as that
can be.

---
TerminateThread causes the thread to exit unexpectedly. The thread then
has no chance to execute any user-mode code and its initial stack in not
deallocated. Furthermore, any DLLs attached to the thread are not
notified that the thread is terminating."

TerminateThread is a dangerous function that should only be used in the
most extreme cases. You should call TerminateThread only if you know
exactly what the target thread is doing, and you control all of the code
that the target thread could possibly be running at the time of the
termination. For example, TerminateThread can result in the following
problems:

    * If the target thread owns a critical section, the critical section
      will not be released.
    * If the target thread is allocating memory from the heap, the heap
      lock will not be released.
    * If the target thread is executing certain kernel32 calls when it
      is terminated, the kernel32 state for the thread's process could
      be inconsistent.
    * If the target thread is manipulating the global state of a shared
    * DLL, the state of the DLL could be destroyed, affecting other
      users of the DLL.
---

[]s,
Diego.