Ken,
That's interesting, and might be particularly so to anyone who cares about doing things efficiently on Windows. I say that because there is some perhaps dated literature from the NT days that dismantled the conventional wisdom that native threads always beat green threads. Basically, they found that the NT schueduler was fairly pathetic and that a good green thread scheduler handing out asynch events would beat its fumblings with blocking calls.
For now, I am far more concerned about coding something in a reasonble time than trying to keep up with Amazon's web traffic. The asynch side of OpenSSL is very flexible, and IIRC, **very** complicated. For now, I would be happy to get the blocking calls working and to signal semaphores or raise errors when they complete. That should be enough to let the image keep running when the outside world does not answer quickly for any reason.
Bill
-----Original Message-----
From:
[hidden email] [mailto:
[hidden email]] On Behalf Of Ken.Dickey
Sent: Sunday, September 06, 2009 3:33 PM
To:
[hidden email]
Subject: [Pharo-project] Building a VM and/or plugins
> "Schwab,Wilhelm K" <
[hidden email]>
...
> The question then becomes whether to connect to OpenSSL via FFI/Alien
> or to make a plugin. One absolute requirement is that the image not
> turn to stone when an address is wrong, a peer crashes, or a router
> gets unplugged w/o warning. The most obvious solution to me (please
> speak up if you
> disagree) is to connect/bind, read/write and disconnect on a
> connection-specific OS thread.
I would think a separate thread (or process) is required to handle and recover from bad pointer references.
For general client/server multiplexing however, you might look at liboop for
ideas:
http://liboop.ofb.net/"Liboop is a low-level event loop management library for POSIX-based operating systems. It supports the development of modular, multiplexed applications which may respond to events from several sources. It replaces the "select() loop" and allows the registration of event handlers for file and network I/O, timers and signals. Since processes use these mechanisms for almost all external communication, liboop can be used as the basis for almost any application."
There are refs to other event dispatchers on the liboop web page.
FYI,
-KenD
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Locked
