[Gambas-user] Important change in revision #6691

Jussi Lahtinen jussi.lahtinen at ...626...
Wed Dec 3 19:35:15 CET 2014


/dev/full should never be writable, is it possible for watch to know
whether there is space left in disk? Or is this job for an other function?
See attachment. I'll remove that test if it is not applicable.


Jussi

On Wed, Dec 3, 2014 at 8:04 PM, Jussi Lahtinen <jussi.lahtinen at ...626...>
wrote:

> Thanks for all the hard work!!!
>
> Poking some more of watch... is my method flawed or is there bug to
> prevent watch to call read event?
> See attachment.
>
>
> Jussi
>
> On Wed, Dec 3, 2014 at 2:04 AM, Jussi Lahtinen <jussi.lahtinen at ...626...>
> wrote:
>
>> Watch seems to raise read event for empty file, is this correct behavior?
>> From the documentation ( http://gambaswiki.org/wiki/lang/open ) I would
>> say it shouldn't.
>> See the attachment.
>>
>>
>> Jussi
>>
>> On Mon, Dec 1, 2014 at 12:52 AM, Benoît Minisini <
>> gambas at ...1...> wrote:
>>
>>> Hi,
>>>
>>> I'm trying to fix a problem in the Gambas process management that annoys
>>> a lot of people for a long time.
>>>
>>> Sometimes, the output of the process is not entirely read. Some data is
>>> lost.
>>>
>>> This is because I was using a way of detecting data availability that
>>> was not reliable. I thought it was, but I was wrong.
>>>
>>> Concretely, the select() system call tells you if there is data
>>> available to read, but, in some cases, it wakes up and there is actually
>>> no data to read.
>>>
>>> So I tried to use a end-of-stream check by using various system calls
>>> (it depends on the type of file descriptor: file, pipe, socket...). But
>>> this routine sometimes fails.
>>>
>>> To change that, I now read data ahead by chunk of 1KB before actually
>>> raising the Read event.
>>>
>>> Apparently, using select() + read() is the correct way of accurately
>>> detecting end of stream, especially on pipes.
>>>
>>> Consequently, if the read ahead fails, I decide there is nothing to read
>>> anymore and I close the stream.
>>>
>>> Hopefully, this was not a big job, as internally read ahead was already
>>> implemented for optimizing the INPUT and LINE INPUT instruction.
>>>
>>> But this is a big change that may have side effects, so I ask people who
>>> run Gambas projects that watch a lot of file descriptors, and read the
>>> output of a lot of external processes, to use that revision and report
>>> any problem.
>>>
>>> Regards,
>>>
>>> --
>>> Benoît Minisini
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Gambas-user mailing list
>>> Gambas-user at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/gambas-user
>>>
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GambasTestercmd-0.9.44.tar.gz
Type: application/x-gzip
Size: 17615 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20141203/78e67786/attachment.bin>


More information about the User mailing list