stream_pool_test.c
2.47 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
#include <scot/stream.h>
#include <scot/stream_pool.h>
/*
* ok, zunächst ein paar Gedanken.
* Also ein großes Problem sehe ich leider jetzt erst. Als Beispiel
* dient ein filedescriptor (fd) von dem gelesen werden soll.
* Nachdem dieser in einem stream_pool registriert wurde und der
* stream pool thread gestartet wurde:
* sobald der fd bereit zu lesen ist, schreibt der event pool thread ein
* event nach dem nächsten in die event-queue, solange bis alle daten
* weggelesen wurden.
*
* Es muessen also immer alle passenden read-events aus der queue geflushed
* werden (solange events aus der queue gelesen, solange sie mit dem
* ersten gefundenen event übereinstimmen)
* und dann kann solange gelesen werden bis der zurückgegebene
* wert von read kleiner ist als die gewünschte (puffer) größe.
*
* Es kann trotzdem vorkommen, das noch read events in der queue sind,
* obwohl bereits alle daten gelesen wurden. Die wurden in die queue
* gestellt bevor die Daten gelesen wurden.
*
* Eine mögliche Lösung schein nur non-blocking file operation zu nutzen.
* wenn dann ein read event auftaucht aber keine daten da sind
* blockiert der callback nicht und kann evtl. darauf reagieren das
* keine Daten vorlagen.
*
* Eine weitere option ist, ein event zu lesen, und danach die gesamte queue
* leer zu lesen....dann währen alle weiteren read events weg, wenn noch
* daten zu lesen wären würde aber wieder ein read event erzeugt. Auf
* das dann wieder reagiert werden könnte.
*
* Die beste option wäre sicherlich eine programminterne queue
* zu verwenden (queue_scot_event_t_node_t) und semaphore um
* blocking zu realisieren. Dann kann eine event source aber kein
* sub prozess sein, sondern nur ein thread...es sei denn wir propagieren
* die queueu irgendwie in shared memory oder mmio oder so was.
* Vorteil die queue läst sich direkt von source und sink manipulieren.
*
* Oder aber ich implementier tatsächlich ein Kommunikationsprotokoll
* zwischen event source und event sink mit dem die sink anforderungen
* an sie source schicken kann. Auch dann wäre eine Liste ohne pipe
* und mit semaphoren zum blockieren die interne Struktur der wahl.
* !!!anmerkung, da ich ja nur threads verwenden will tuts auch ein
* pthread_mutex, bzw ein windows mutex object. !!!
*/
int
read_cb (struct scot_stream_pool_event * ev)
{
char buffer [1024];
return 0;
}
int
main (int argc, char * argv [])
{
return 0
}