| 1 |
- |
| 2 |
02 10:21:00 <schmorp> ich wüsste nicht, wie man es anders machen kann |
| 3 |
02 10:21:11 <schmorp> ach ja |
| 4 |
02 10:21:23 <schmorp> man muss auch nen "custom"-read prependen/appenden können |
| 5 |
02 10:21:33 <schmorp> außerdem wäre ein resource-limit nicht dumm |
| 6 |
02 10:21:34 <schmorp> also |
| 7 |
02 10:21:38 <schmorp> "maximal 16mb zeilen lesen" |
| 8 |
02 10:21:41 <schmorp> oder allgemein |
| 9 |
02 10:21:47 <schmorp> "rbuf darf nie > 16mb werden" |
| 10 |
02 10:22:01 <elmex> ja, das waehre praktisch |
| 11 |
02 10:22:06 <schmorp> praktisch nicht |
| 12 |
02 10:22:08 <schmorp> aber wichtig :) |
| 13 |
02 10:22:11 <elmex> jo |
| 14 |
02 10:22:19 <schmorp> für die sicherheit |
| 15 |
02 10:22:23 <schmorp> prkatisch ists eher im wege |
| 16 |
02 10:22:25 <elmex> wenn rbuf > 16mb dann liest er nicht mehr? oder was soll dann passieren? |
| 17 |
02 10:23:00 <elmex> nicht mehr lesen waehre schwierig, da muesste man den watcher entfernen und wieder reinstallieren wenn der |
| 18 |
buffer leerer is |
| 19 |
02 10:23:20 <schmorp> wozu? |
| 20 |
02 10:23:33 <schmorp> leerer(?) |
| 21 |
02 10:23:39 <schmorp> wie kann er dnen leerer werden? |
| 22 |
02 10:23:42 <elmex> eben :) |
| 23 |
02 10:23:53 <elmex> wenn die daten verarbeitet wurden und jemand den buffer leere gemacht hat |
| 24 |
02 10:23:57 <schmorp> ah, das ist ein verständnisproblem |
| 25 |
02 10:24:01 <schmorp> es geht um harte fehler |
| 26 |
02 10:24:04 <schmorp> sicherheit! |
| 27 |
02 10:24:06 <schmorp> denial-of-service |
| 28 |
02 10:24:14 <schmorp> nicht um speicherersparnis |
| 29 |
02 10:24:21 <schmorp> wenn du sagst, der rbug darf nie >16mb werden |
| 30 |
02 10:24:29 <schmorp> dann ist es ein harter fehler/verbindungssbbaruch |
| 31 |
02 10:24:31 <schmorp> wenbne r größer wird |
| 32 |
02 10:24:33 <schmorp> dananch ist ende |
| 33 |
02 10:24:38 <elmex> hmmm, also waehre das beste ein extra callback fuer den fall? und das default evrhalten is ein error und d |
| 34 |
ann ->close ? |
| 35 |
02 10:24:46 <schmorp> ich würde sagen on_error |
| 36 |
02 10:24:48 <schmorp> wie alles andere |
| 37 |
02 10:24:50 <elmex> hm, ok |
| 38 |
02 10:24:57 <schmorp> ein fehler ist fatal |
| 39 |
02 10:24:58 <elmex> sie koennen das limit ja einstellen |
| 40 |
02 10:25:03 <schmorp> kannst $! auf ENOSPC setzen |
| 41 |
02 10:25:06 <elmex> ok |
| 42 |
02 10:25:11 <schmorp> ja, es kann ja per default aus sein von mir aus |
| 43 |
|
| 44 |
- und ganz wichtig: generell die api fixen |
| 45 |
|
| 46 |
- |
| 47 |
02 10:27:36 <schmorp> reply 1 |
| 48 |
02 10:27:38 <schmorp> reply 1, zweiter teil |
| 49 |
02 10:27:39 <schmorp> reply 2 |
| 50 |
02 10:27:42 <elmex> ahja |
| 51 |
02 10:27:46 <elmex> genau |
| 52 |
02 10:27:48 <schmorp> dazu musst du den read vor den reply 2 quetschen |
| 53 |
02 10:27:54 <elmex> also prependen |
| 54 |
02 10:27:56 <schmorp> ja |
| 55 |
02 10:28:02 <elmex> ja, ich dachte halt an den fall: |
| 56 |
02 10:28:03 <schmorp> eventuell kann man shift/push nehmen als namen |
| 57 |
02 10:28:19 <schmorp> ausserdem muss es noch einen generic-callback geben |
| 58 |
02 10:28:28 <schmorp> die frage ist, wie man "progress" feststellt |
| 59 |
02 10:28:31 <elmex> reply 1, reply 2, und bei reply 1 wird ein zweiter request gemacht wo reply 3 kommt, und der read-cb fuer |
| 60 |
reply 3 muss halt hinter reply 2 |
| 61 |
02 10:28:37 <schmorp> man könnte z.b. die länge des rbufs vor und anch dme callback checken |
| 62 |
02 10:28:38 <elmex> in dem fall will man appenden |
| 63 |
02 10:28:42 <schmorp> wenn sie sich ändert, mach weiter |
| 64 |
02 10:28:54 <schmorp> elmex: genau |
| 65 |
02 10:29:07 <schmorp> elmex: deshalb gehen auch keien schemata wie "im callback prependen, ausserhalb appenden" |
| 66 |
02 10:29:18 <elmex> jo |
| 67 |
02 10:29:23 <elmex> das is halt protokollabhaengig |
| 68 |
02 10:29:34 <schmorp> igentlich nicht so |
| 69 |
02 10:29:42 <schmorp> es hängt davon ab, was dein programm macht |
| 70 |
02 10:29:45 <schmorp> vom protkoll weniger |
| 71 |
02 10:29:46 <elmex> was meinst du mit einem generic callback? |
| 72 |
02 10:29:48 <elmex> ja, stimmt |
| 73 |
02 10:29:49 <schmorp> denn das ist hier immer tcp |
| 74 |
02 10:29:57 <schmorp> sprich, reioehenfolge bleibt reihenfolge |
| 75 |
02 10:30:21 <schmorp> vielleicht wäre es auch nett, einen default-read-callback zu haben |
| 76 |
02 10:30:28 <schmorp> aber ich denke, das kann on_read erledigen |
| 77 |
02 10:30:33 <schmorp> d.gh. die queue hat vorrang vor on_read |
| 78 |
02 10:30:40 <schmorp> aber wenn die queu leer ist, wird on_read aufgerufen |
| 79 |
02 10:30:44 <elmex> jo |
| 80 |
02 10:30:45 <schmorp> undd as kannd ann z.b. nichts tun |
| 81 |
02 10:30:48 <schmorp> außer ein realine pushen |
| 82 |
02 10:30:54 <schmorp> bzw. prependen :/ |
| 83 |
02 10:31:04 <elmex> hmm |
| 84 |
02 10:31:08 <schmorp> alsowas, prepend/append doer shift/push |
| 85 |
02 10:31:21 <schmorp> unshift/push natürlich |
| 86 |
02 10:31:31 <elmex> was soll der default callback machen? |
| 87 |
02 10:31:40 <elmex> ich meine, bisher tut on_read einfach in rbuf lesen |
| 88 |
02 10:31:41 <schmorp> welcher default-callback? |
| 89 |
02 10:31:49 <elmex> default-read-callback |
| 90 |
02 10:31:56 <schmorp> es kann keinen geben? |
| 91 |
02 10:31:57 <elmex> ich kann dir im mom nich ganz forlgen :) |
| 92 |
02 10:31:59 <schmorp> was kann der auch tun? |
| 93 |
02 10:32:04 <schmorp> du hats ne socket |
| 94 |
02 10:32:06 <schmorp> auf der kommen daten |
| 95 |
02 10:32:10 <schmorp> aber niemand verarbeiotet sie |
| 96 |
02 10:32:14 <schmorp> trottzdem pufferst du sie |
| 97 |
02 10:32:16 <schmorp> das macht keinen sinn |
| 98 |
02 10:32:22 + Muttley joined #schmorp (JOIN, #schmorp) |
| 99 |
02 10:32:23 <elmex> hmm, das tu ich auch net |
| 100 |
02 10:32:24 <schmorp> es _muss_ immer einen callback geben für lesedaten |
| 101 |
02 10:32:25 <schmorp> ODER |
| 102 |
02 10:32:29 <Muttley> Morning |
| 103 |
02 10:32:30 <schmorp> er darf nicht lesen |
| 104 |
02 10:32:34 <schmorp> Muttley: hi pauk |
| 105 |
02 10:32:40 <schmorp> Muttley: didn't we want a firmware today? |
| 106 |
02 10:32:44 <schmorp> (sometime) |
| 107 |
02 10:32:54 <Muttley> If you would be so kind, that would be great :) |
| 108 |
02 10:32:56 <elmex> schmorp: bisher machts ::Handle halt so, das er nicht liest wenn niemand einen callback fuers lesen instal liert hat. ich dachte das sollte ruhig weiter so sein |
| 109 |
02 10:33:00 <schmorp> Muttley: right now? |
| 110 |
02 10:33:13 <schmorp> elmex: ja, das ist gut |
| 111 |
02 10:33:19 <schmorp> elmex: aber dann gibts auch keinen default-fall |
| 112 |
|
| 113 |
02 11:43:38 <schmorp> $socket->push_read_line ([$sep, ]$cb) |
| 114 |
02 11:43:49 <schmorp> oder read-handler müsste dann "nur" folgendes machen: |
| 115 |
02 11:43:51 <schmorp> sysread |
| 116 |
02 11:43:58 <schmorp> if (!queue) on_read |
| 117 |
02 11:44:00 <schmorp> else |
| 118 |
02 11:44:07 <schmorp> while() |
| 119 |
02 11:44:14 <schmorp> queu[0]->callback |
| 120 |
02 11:44:22 <schmorp> if (!progress) |
| 121 |
02 11:44:30 <schmorp> if (eof-föag) on_eof; |
| 122 |
02 11:44:32 <schmorp> last |
| 123 |
02 11:44:45 <schmorp> shift queue |
| 124 |
02 11:44:52 <schmorp> scheiss python-whitespace-indenting |
| 125 |
|
