John McDermott wrote:
Could you tell it via the sync_pipe?
Well, I think I'll have to in a way.
There may be some issues if the child ends ungracefully, however.
Yes there are. But I would guess they are (almost) the same we currently
handle with a single file (or at least I don't see real differences), so
these problems should be solved already.
To avoid that, perhaps you could have the client write it to a file
in /tmp (or %TEMP% or whatever) each time it opens a file.
Write *what* to a tmp file?
I would guess it might be the best idea that the child should open and
close the capturing files in any case. This scheme must be used IMHO in
the ringbuffer case, as the child shouldn't have to wait for the client
to open a new (ringbuffer) file when the old is "full".
BTW: in future (as I can see no difference any longer) I will try to
keep the single and ringbuffer file cases exactly the same way, as the
single file is only a "special case" of the ringbuffer file mode. This
way, I will keep the implementation as simple as possible. This wasn't
possible in the past, as the "two task" and "ringbuffer" modes weren't
compatible in the implementation (which is what I try to solve here ;-)
Saying this, a simple but working solution might be: The client will
pass the (temporary or user's) filename to the client and when the child
opens the first/next file, it will send the currently used filename
(e.g. the current ringbuffer filename) at that moment to the client.
However, I currently don't know the correct marshalling for this, but
we'll see.
Regards, ULFL