[9fans] Thread library

[9fans] Thread library

[Andrew Simmons]

Does anyone know of a port of the Plan 9 thread library to Windows NT?

Re: [9fans] Thread Library

[Russ Cox]

> But the point is that you are only dealing with sockets.
> 
> Try it on stdin ...

Not to defend NT, but you can use WaitForMultipleObjects
and hand it both the input console handle and a socket.
You can also hand it semaphores, processes (wait until
they die), threads.  In general I find this much more 
useful than Unix's select.  At least in NT everything
is a handle.  

Russ

Re: [9fans] Thread Library

[Boyd Roberts]

erik quanstrom wrote:
> 
> not to defend nt, but i had no problem calling select() from
> the wsa library.

But the point is that you are only dealing with sockets.

Try it on stdin ...

Re: [9fans] Thread Library

[erik quanstrom]

not to defend nt, but i had no problem calling select() from
the wsa library. i did create an include file that mapped the
errors from WSAx to Ey and hid all the include nasties (unix
is even worse than nt in this case). it looked like:

------

#if defined(NT)
#define boolean _fuck_windows_
#include <winsock.h>
#undef boolean

#ifndef EWOULDBLOCK
#define EWOULDBLOCK             WSAEWOULDBLOCK
#define EINPROGRESS             WSAEINPROGRESS
#define EALREADY                WSAEALREADY
#define ENOTSOCK                WSAENOTSOCK
#define EDESTADDRREQ            WSAEDESTADDRREQ
#define EMSGSIZE                WSAEMSGSIZE
#define EPROTOTYPE              WSAEPROTOTYPE
#define ENOPROTOOPT             WSAENOPROTOOPT
#define EPROTONOSUPPORT         WSAEPROTONOSUPPORT
#define ESOCKTNOSUPPORT         WSAESOCKTNOSUPPORT
#define EOPNOTSUPP              WSAEOPNOTSUPP
#define EPFNOSUPPORT            WSAEPFNOSUPPORT
#define EAFNOSUPPORT            WSAEAFNOSUPPORT
#define EADDRINUSE              WSAEADDRINUSE
#define EADDRNOTAVAIL           WSAEADDRNOTAVAIL
#define ENETDOWN                WSAENETDOWN
#define ENETUNREACH             WSAENETUNREACH
#define ENETRESET               WSAENETRESET
#define ECONNABORTED            WSAECONNABORTED
#define ECONNRESET              WSAECONNRESET
#define ENOBUFS                 WSAENOBUFS
#define EISCONN                 WSAEISCONN
#define ENOTCONN                WSAENOTCONN
#define ESHUTDOWN               WSAESHUTDOWN
#define ETOOMANYREFS            WSAETOOMANYREFS
#define ETIMEDOUT               WSAETIMEDOUT
#define ECONNREFUSED            WSAECONNREFUSED
#define ELOOP                   WSAELOOP
#define EHOSTDOWN               WSAEHOSTDOWN
#define EHOSTUNREACH            WSAEHOSTUNREACH
#define EPROCLIM                WSAEPROCLIM
#define EUSERS                  WSAEUSERS
#define EDQUOT                  WSAEDQUOT
#define ESTALE                  WSAESTALE
#define EREMOTE                 WSAEREMOTE
#endif

#else
#include <netdb.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#endif

----------

Russ Cox wrote:
> To the best of my knowledge, you can't implement threadkill
> completely on NT since I don't see how to send an interrupt to
> another process.

I'm pretty sure you can't.  The best you can do is send it a message
to _persuade_ it to pack it in.  My theory is that the program loader,
oops kernel, forcibly kills processes by ripping them out of memory
and throwing away their kernel resources.

The whole model is totally and utterly flawed.

I guess you could have a thread manager thread that receives a
threadkill messages and kills 'em.  Such revolting hacks are often
the only way to do it.

Try writing rsh [remote shell] on NT.  You can't select [WaitForMultipleObjects
or whatever it's called] on sockets ...  It's doable, but revolting.

Re: [9fans] Thread library

[Boyd Roberts]

Russ Cox wrote:
> To the best of my knowledge, you can't implement threadkill
> completely on NT since I don't see how to send an interrupt to
> another process.

I'm pretty sure you can't.  The best you can do is send it a message
to _persuade_ it to pack it in.  My theory is that the program loader,
oops kernel, forcibly kills processes by ripping them out of memory
and throwing away their kernel resources.

The whole model is totally and utterly flawed.

I guess you could have a thread manager thread that receives a
threadkill messages and kills 'em.  Such revolting hacks are often
the only way to do it.

Try writing rsh [remote shell] on NT.  You can't select [WaitForMultipleObjects
or whatever it's called] on sockets ...  It's doable, but revolting.

Re: [9fans] Thread library

[nigel]

[-- Attachment #1: Type: text/plain, Size: 55 bytes --]

You mean interrupt a system call? I don't think so.


[-- Attachment #2: Type: message/rfc822, Size: 1564 bytes --]

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Thread library
Date: Mon, 4 Feb 2002 21:31:15 -0500
Message-ID: <1ae0b0262b7b842b424abcf81dc0fd0f@plan9.bell-labs.com>

I have a very recent one.  So recent that I'm still
finding bugs in it.  Once I've used it more and am
convinced that it's solid, I'll put it up somewhere.
Ditto for the associated Unix ports.  To the best of
my knowledge, you can't implement threadkill completely
on NT since I don't see how to send an interrupt to
another process.  If anyone knows how, I'd appreciate
hearing.  Thanks.

Russ

Re: [9fans] Thread library

[Russ Cox]

I have a very recent one.  So recent that I'm still
finding bugs in it.  Once I've used it more and am
convinced that it's solid, I'll put it up somewhere.
Ditto for the associated Unix ports.  To the best of
my knowledge, you can't implement threadkill completely
on NT since I don't see how to send an interrupt to
another process.  If anyone knows how, I'd appreciate
hearing.  Thanks.

Russ