You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
61 lines
2.5 KiB
61 lines
2.5 KiB
#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
|
|
}
|