X-Git-Url: https://arthur.barton.de/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2FREADME-BeOS.txt;h=ad593c89bfebdb3c070a6be66e00b8ab9635bfb6;hb=1f9ba7b326d05a681129f67f3f65853bb4969e76;hp=77f8784331735726cfe758730614dff9ddec99e5;hpb=b7a6bf27cc16ce40a0a3fa6f71b86313c8b8b146;p=ngircd-alex.git

diff --git a/doc/README-BeOS.txt b/doc/README-BeOS.txt
index 77f87843..ad593c89 100644
--- a/doc/README-BeOS.txt
+++ b/doc/README-BeOS.txt
@@ -22,7 +22,7 @@ von Pipes verschiedener Prozesse umgehen kann: sobald der Resolver asyncron
 gestartet wird, also Pipe-Handles im select() vorhanden sind, fuehrt das zu
 obiger Meldung.
 
-Theoretische "Lösung"/Workaround:
+Theoretische "Loesung"/Workaround:
 Den Resolver unter BeOS nicht verwenden, sondern mit IP-Adressen arbeiten.
 Nachteil: der ngIRCd koennte sich nicht zu Servern verbinden, die dynamische
 Adressen benutzen -- dazu muesste er den Namen aufloesen. Ansonsten sollte
@@ -32,5 +32,16 @@ Also: wenn es jemand implementieren will ... ;-))
 
 Vielleicht mache ich es auch irgendwann mal selber. Mal sehen.
 
+2002-05-19:
+Ich habe gerade damit ein wenig gespielt und den Source hier so geaendert,
+dass unter BeOS keine Resolver-Subprozesse mehr erzeugt werden, sondern mit
+den "rohen" IP-Adressen gearbeitet wird. Das funktioniert so weit auch,
+allerdings verschluckt sich BeOS nun bei anderen Funktionen, so zum Beispiel
+bei close(), wenn ein Socket eines Clients geschlossen werden soll!?
+Sehr komisch.
+Wer Interesse daran hat, das weiter zu verfolgen, der moege sich bitte mit
+mir in Verbindung setzen (alex@barton.de), ich maile gerne meine Patches zu.
+Fuer eine Aenderung im CVS ist es aber meiner Meinung nach noch zu frueh ...
+
 -- 
-$Id: README-BeOS.txt,v 1.1 2002/02/25 14:02:32 alex Exp $
+$Id: README-BeOS.txt,v 1.3 2002/05/19 13:10:26 alex Exp $